You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2012/09/10 14:31:14 UTC
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)
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Thu, Sep 13, 2012 at 9:54 AM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:
> On Thu, Sep 13, 2012 at 4:45 PM, Jeremy Thomerson
> <je...@wickettraining.com> 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 start looking into wicket 7 around 6.3/6.4-ish.
>
>
Do we have a roadmap somewhere of any big changes that would be in 7?
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Releasing in a semver world (>= 6.x)
Posted by Martijn Dashorst <ma...@gmail.com>.
On Thu, Sep 13, 2012 at 4:45 PM, Jeremy Thomerson
<je...@wickettraining.com> 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 start looking into wicket 7 around 6.3/6.4-ish.
Martijn
Re: Releasing in a semver world (>= 6.x)
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Thu, Sep 13, 2012 at 9:40 AM, Martijn Dashorst <
martijn.dashorst@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.0 -> build on fri 21-09-2012 -> release on tue 25-09-2012
> 6.2.0 -> build on fri 19-10-2012 -> release on tue 23-10-2012
> 6.3.0 -> build on fri 16-11-2012 -> release on tue 20-11-2012
> ...
>
> I intend to be the release manager for the 6.y.0 releases.
>
> WDYT?
>
I like it.
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.
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Releasing in a semver world (>= 6.x)
Posted by Andreas Pieber <an...@gmail.com>.
+1 (non-binding)
Kind regards,
Andreas
On Thu, Sep 13, 2012 at 4:40 PM, Martijn Dashorst
<ma...@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.0 -> build on fri 21-09-2012 -> release on tue 25-09-2012
> 6.2.0 -> build on fri 19-10-2012 -> release on tue 23-10-2012
> 6.3.0 -> build on fri 16-11-2012 -> release on tue 20-11-2012
> ...
>
> I intend to be the release manager for the 6.y.0 releases.
>
> WDYT?
>
> Martijn
Re: Releasing in a semver world (>= 6.x)
Posted by Emond Papegaaij <em...@topicus.nl>.
+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 21-09-2012 -> release on tue 25-09-2012
> 6.2.0 -> build on fri 19-10-2012 -> release on tue 23-10-2012
> 6.3.0 -> build on fri 16-11-2012 -> release on tue 20-11-2012
> ...
>
> I intend to be the release manager for the 6.y.0 releases.
>
> WDYT?
>
> Martijn
Re: Releasing in a semver world (>= 6.x)
Posted by Martijn Dashorst <ma...@gmail.com>.
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 -> release on tue 23-10-2012
6.3.0 -> build on fri 16-11-2012 -> release on tue 20-11-2012
...
I intend to be the release manager for the 6.y.0 releases.
WDYT?
Martijn
Re: Releasing in a semver world (>= 6.x)
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Thu, Sep 13, 2012 at 9:34 AM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:
> On Thu, Sep 13, 2012 at 4:25 PM, Jeremy Thomerson
> <je...@wickettraining.com> 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 time and effort to
> actually perform such a release.
Seems reasonable to me.
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Releasing in a semver world (>= 6.x)
Posted by Martijn Dashorst <ma...@gmail.com>.
On Thu, Sep 13, 2012 at 4:25 PM, Jeremy Thomerson
<je...@wickettraining.com> 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 time and effort to
actually perform such a release.
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Releasing in a semver world (>= 6.x)
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Tue, Sep 11, 2012 at 8:18 AM, Andrea Del Bene <an...@gmail.com>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
>> 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
>>
>
>
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?
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Releasing in a semver world (>= 6.x)
Posted by Andrea Del Bene <an...@gmail.com>.
+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 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)
Posted by Emond Papegaaij <em...@topicus.nl>.
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)
Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
+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 <ig...@gmail.com> wrote:
> +1 for option B.
>
> -igor
>
> On Mon, Sep 10, 2012 at 5:31 AM, Martijn Dashorst
> <ma...@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)
Posted by Andreas Pieber <an...@gmail.com>.
+1 for opt B from my side too (non-binding)
Kind regards,
Andreas
On Mon, Sep 10, 2012 at 8:14 PM, Johan Compagner <jc...@gmail.com> 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 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" <cm...@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 <ig...@gmail.com> wrote:
>>
>> > +1 for option B.
>> >
>> > -igor
>> >
>> > On Mon, Sep 10, 2012 at 5:31 AM, Martijn Dashorst
>> > <ma...@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)
Posted by Johan Compagner <jc...@gmail.com>.
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" <cm...@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 <ig...@gmail.com> wrote:
>
> > +1 for option B.
> >
> > -igor
> >
> > On Mon, Sep 10, 2012 at 5:31 AM, Martijn Dashorst
> > <ma...@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)
Posted by Igor Vaynberg <ig...@gmail.com>.
+1 for option B.
-igor
On Mon, Sep 10, 2012 at 5:31 AM, Martijn Dashorst
<ma...@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