Sure! Long post incoming
TLDR: chapter 3, section 4 branching workflows or the cactus model
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