Re: Releasing in a semver world (>= 6.x)

2012-09-13 Thread Jeremy Thomerson
On Thu, Sep 13, 2012 at 9:54 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > On Thu, Sep 13, 2012 at 4:45 PM, Jeremy Thomerson > wrote: > > My OCD side wonders if we should have used two-digit numbers ( at least > for > > y and z ) to improve sortability (6.01.00) ... but then those l

Re: Releasing in a semver world (>= 6.x)

2012-09-13 Thread Andreas Pieber
+1 (non-binding) Kind regards, Andreas On Thu, Sep 13, 2012 at 4:40 PM, Martijn Dashorst wrote: > As for performing the releases, I propose we maintain a ~4 week > schedule for x.y.0 releases, and reserve x.y.z (z > 0) for botched > releases. > > So our release calendar would become something li

Re: Releasing in a semver world (>= 6.x)

2012-09-13 Thread Martijn Dashorst
On Thu, Sep 13, 2012 at 4:45 PM, Jeremy Thomerson wrote: > My OCD side wonders if we should have used two-digit numbers ( at least for > y and z ) to improve sortability (6.01.00) ... but then those look kind of > ugly. FUGLY is a proper characterization. And I just say that we should probably st

Re: Releasing in a semver world (>= 6.x)

2012-09-13 Thread Jeremy Thomerson
On Thu, Sep 13, 2012 at 9:40 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > As for performing the releases, I propose we maintain a ~4 week > schedule for x.y.0 releases, and reserve x.y.z (z > 0) for botched > releases. > > So our release calendar would become something like: > > 6.1

Re: Releasing in a semver world (>= 6.x)

2012-09-13 Thread Emond Papegaaij
+1 On Thursday 13 September 2012 16:40:19 Martijn Dashorst wrote: > As for performing the releases, I propose we maintain a ~4 week > schedule for x.y.0 releases, and reserve x.y.z (z > 0) for botched > releases. > > So our release calendar would become something like: > > 6.1.0 -> build on fri

Re: Releasing in a semver world (>= 6.x)

2012-09-13 Thread Martijn Dashorst
As for performing the releases, I propose we maintain a ~4 week schedule for x.y.0 releases, and reserve x.y.z (z > 0) for botched releases. So our release calendar would become something like: 6.1.0 -> build on fri 21-09-2012 -> release on tue 25-09-2012 6.2.0 -> build on fri 19-10-2012 -> relea

Re: Releasing in a semver world (>= 6.x)

2012-09-13 Thread Jeremy Thomerson
On Thu, Sep 13, 2012 at 9:34 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > On Thu, Sep 13, 2012 at 4:25 PM, Jeremy Thomerson > wrote: > > So, just to be clear - this means that when I fix a bug in master right > now > > I put fix version of "6.1.0" in, right? > > Yup. > > I propose

Re: Releasing in a semver world (>= 6.x)

2012-09-13 Thread Martijn Dashorst
On Thu, Sep 13, 2012 at 4:25 PM, Jeremy Thomerson wrote: > So, just to be clear - this means that when I fix a bug in master right now > I put fix version of "6.1.0" in, right? Yup. I propose that for each back port to a possible x.y.z release we at least ping dev@ prior to making one: it costs

Re: Releasing in a semver world (>= 6.x)

2012-09-13 Thread Jeremy Thomerson
On Tue, Sep 11, 2012 at 8:18 AM, Andrea Del Bene wrote: > +1 for B. IMHO it's more rational > > 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 >> d

Re: Releasing in a semver world (>= 6.x)

2012-09-11 Thread Andrea Del Bene
+1 for B. IMHO it's more rational 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 re

Re: Releasing in a semver world (>= 6.x)

2012-09-11 Thread Andreas Pieber
+1 for opt B from my side too (non-binding) Kind regards, Andreas On Mon, Sep 10, 2012 at 8:14 PM, Johan Compagner wrote: > 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 the

Re: Releasing in a semver world (>= 6.x)

2012-09-10 Thread Johan Compagner
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"

Re: Releasing in a semver world (>= 6.x)

2012-09-10 Thread Carl-Eric Menzel
+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 powe

Re: Releasing in a semver world (>= 6.x)

2012-09-10 Thread Igor Vaynberg
+1 for option B. -igor On Mon, Sep 10, 2012 at 5:31 AM, 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 communicatio

Re: Releasing in a semver world (>= 6.x)

2012-09-10 Thread Emond Papegaaij
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 s

Releasing in a semver world (>= 6.x)

2012-09-10 Thread Martijn Dashorst
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 de