+1 for B as well. We also need to think about how we will actually *do* the branching, and especially the merging. So far what I've seen were three totally separate branches with only cherry-picking going in between them. In my opinion, that's not a very good way to use git, which is far more powerful than that.
I don't have time right now, but I hope to soon write a short article on how we do it in my current project, and offer that up for comments. Carl-Eric On Mon, 10 Sep 2012 09:05:20 -0700 Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > +1 for option B. > > -igor > > On Mon, Sep 10, 2012 at 5:31 AM, Martijn Dashorst > <martijn.dasho...@gmail.com> wrote: > > We now live in a semver world and we need to agree on some basics: > > how we are going to maintain and release our software. > > > > From what I have heard from several folks in jira, mail, IRC and > > direct communication is that we have basically 2 camps: > > > > A. develop and release bug fixes until we we start developing for > > minor/major releases 6.1 (and 7.0). > > > > versus > > > > B. develop and release minor releases, only backporting critical > > bugs and releasing bug fix releases in case of critical bugs > > > > As we are following semver, both are valid strategies. > > > > Option A would require separate branches for 6.0.z, and 6.y > > Option B would require only branches 6.y.z when critical bugs are > > found—which should be rare. > > > > Option A would probably result in some releases like: > > - 6.0.1, 6.0.2, 6.0.3, 6.1.0, 6.0.4, 6.1.1, 6.1.2, 6.1.3, 6.0.5, > > 6.2.0, 6.1.4 > > > > Whereas option B should result in releases like: > > - 6.1.0, 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.4.1 > > > > What do you think? > > > > Martijn
