Releasing in a semver world (= 6.x)
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
Re: Releasing in a semver world (= 6.x)
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
Re: Releasing in a semver world (= 6.x)
+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
Re: Releasing in a semver world (= 6.x)
+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
Re: Releasing in a semver world (= 6.x)
I am interested in your article.. How else to really do it then cherry picking.. but I guess h that also depends where you do you're good first? I always start at their lowest version I want to fix it and forward port it, almost never do back ports Op 10 sep. 2012 19:33 schreef Carl-Eric Menzel cmen...@wicketbuch.de het volgende: +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
