I opt for the strategy B. Semver dictates that bugfixes should not contain new features. If we stay on 6.0, we cannot add any new features. If I look at JIRA, I already see 6 fixed tickets marked as 'improvement': 4730, 4731, 4736, 4745, 4746 and 4748. If we really want to follow semver, these should not be released in 6.0.1, but will have to wait for 6.1.0. I see no reason why our users would have to wait for these features, therefore, I'd say the next release should be 6.1.0.
Best regards, Emond On Monday 10 September 2012 14:31:14 Martijn Dashorst 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
