+1 I think I like Brane's suggestion (and Cos suggested similar structure before).
- Master should become the development branch for the next release. - All individual ticket branches should be created off of the master branch. - When we are working on the 2 releases in parallel, we should create a special release branch and merge it back to master, once the master branch has been released. - Same CI rules as we have now apply - all tests must pass before the merge to the master branch. This structure is more intuitive and we will have easier structure for the newcomers to understand. I think we should have a vote on it. I will start a separate vote thread. D. On Sun, Jun 7, 2015 at 11:51 AM, Branko Čibej <[email protected]> wrote: > On 07.06.2015 08:35, Branko Čibej wrote: > > * When you're ready to begin stabilization for a release, create a > > release branch (rel-1.2.x for example) from the master branch. Only > > bug fixes happen on the release branch. When you're happy with the > > stability of the release, just tag the release branch (e.g., 1.2.0) > > and publish. This now becomes the bugfix branch for the 1.2.x > release. > > o Its up to you to decide how you fix bugs on the release branch; > > there are basically two ways to do this: > > + Fix all bugs on master and cherry-pick them to the release > > branch(es). This is the preferred method because it ensures > > that all bug fixes are present in all future releases. > > + Fix bugs on the release branches and merge them back to > > master. This works but > > ... requires careful tracking of which bugfix was merged to trunk and > whether or not it was propagated to the other release branches, as > appropriate. > > -- Brane >
