Lately there has been a lot of movement in the repo. Lots of commits with new features, fixes and changes in general, which great! Sadly, keeping up to date or upgrading a Licode installation is very difficult, as there is no pointer to stable versions, experimental features, breaking changes in the API, etc.
My suggestions is to start using Github tags to show this changes. It could be a stable/beta scheme, versions numbers or whatever. Its not a time consuming task and I even offer myself to maintain them if you need help with it.
Tags would not help in this case. You can not checkout a tag and do commits (fix a bug for instance). IMO It’s impossible to keep your installation up to date while there is no stable branch. Users avoid upgrading so as a result there will be no more tests and no feedback from the community. And I wonder if the team are aware of the consequences of this strategy.
In the recent months there have been a lot of progress on development, which is great, but many users got in trouble when installing or upgrading and this is not good for a project.
Creating a stable branch and merging only fixes is not time consuming. It will help not only to keep the community away from the bugs or breaking changes but also let them to get involved in development process.
Thanks for giving your opinion. I totally agree with you on the problems that the project has in these areas. You are right, a stable branch and versioning is for sure a better solution than only tags. And as you say, is painless to create and could be maintained with the help of the community.
It would be great to hear what others think, specially the devs
I totally agree with you guys, due to some changes I had to refactor everything which was translated in rewrite everything from scratch.
It would be very nice to organize the overall work, because we are going in the right direction. The Licode team is doing an huge and really appreciated work, just need to be a little more organized to allow the community to be active and participant.
There are multiple stable branchs and/or release models for opensource projects, but a good start point IMO is the chapter 3, section 4 branchingworkflows from the Git Book.
To make a short summary, the workflow consists in having multiple levels of stabilty and thinking of branches likes silos to hold features in different stability levels. The most stable branch (master) only gets a set of features that have been for certain period of time in the previous stability level (the development branch). New features are created as topic branches and proposed to merge to the development branch through pull requests.
This workflow is pretty similar to how the Licode workflow is right now. The only difference is the added level of stabilty and long-time support of releases, which is critical to any kind of production usage. And for the latests and hotests features the development branch will be there too
An interesting bonus of this kind of branch approach is being able to fix older versions with out mixing in new-features. For example, adding a bug fix to master branch and merging it to the development branch will make the bug fix flow donwards in stability levels with out making instable features flow upwards.
Other models worth considering are “A succesful git branching model”(don’t be tricked by the article’s name, its a complex version of the master-develop one) or a simpler alternative, the cactus model (the one I would choose, its just master + legacy branches for releases).
Please, keep in mind that having a stable, LTS version, doesn’t mean to slower down the release cycle to months or years. Other opensource projects use a 6-week release cylce, for example. Having a semantic versioning system (which is also a must for a project this big) makes it easy to maintain older versions for a longer time.
It would be great to hear other opinions on the matter
Thanks to all of you for your inputs. We are definitely going to start using a kind of Releases control (actually to use it again, because we already did in the past). We will share the details about the procedure during the next few weeks.
