Hey all, let’s talk about Licode versioning.
A better way to identify progress in Licode has been often requested. We feel like we’re doing a better job with the repository, now work is organized under pull requests that document features as we add them. However, we agree that this is not enough and, keeping in touch with what’s new at a given point requires a lot of digging. Furthermore, there’s no easy way to find an stable version. For this and other reasons we’ve decided to implement a release schedule.
Let’s start with the guidelines we’re going to follow starting right now:
- We will use Github Releases.
- Releases will be a tag in the lynckia/licode repository.
- Licode releases will be identified by a single number.
- The number will start with 2 in our first release later today.
- Releases will take place roughly once every month.
- Every release will contain detailed information about the new features and bug fixes introduced.
- You can trust every release has been deployed and used in production environments at least two weeks before its publication.
- Public API changes (changes in ErizoClient’s or Nuve’s API) will be highlighted in the release notes.
- Releases will also be announced here in discourse.lynckia.com
- We won’t patch/bugfix previous releases. Fixes for bugs discovered in a release will be addressed in the next one.
In short, this is what we aim the release schedule and versioning to be:
- A good way to reference the state of Licode at a specific point in time. No more “I’m running a master from April” . Now it should be “I’m running Release 42”
- An indicator of the pace Licode is progressing.
- A periodic checkpoint of stable Licode versions.
- A way to get more timely feedback from you (the community).
Lastly, this is not set in stone. We’re certainly open to revisit and iterate over the processes. Feel free to contribute to the discussion.
FAQ:
Will there be LTS releases?
The short answer is no. We simply don’t have the manpower to maintain multiple releases.
What release would you recommend?
Always the last one, unless a critical problem is found. Then we would advise to use the previous release until a new one is out.
You can (and should) run a staging environment to test new versions and how they interact with your application. Please do report any problems you find in the process.
You can even update to the master branch and help test it before a release.
My fork diverged significantly and it’s complicated work to merge Licode periodically
We encourage you to contribute your code as a pull request if you think Licode can benefit from it. In any case, the release schedule will help you understand what has changed, what may affect your branch and what you’ll be missing if you don’t update Licode.