commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsoftware.com>
Subject RE: [lang] release strategy
Date Mon, 07 Feb 2005 23:36:13 GMT
Personally, I've always liked the following numbering scheme: 

Major.Minor.Maintenance.

Gary

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
Sent: Monday, February 07, 2005 2:08 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] release strategy

Personally I find the three digit release numbers just confusing. I much

prefer to reserve the third digit for essential patches.

So, I'm happy to have a 2.1-branch, but I want the release to be 2.1,
not 
2.1.0 or 2.1.1.

Stephen

----- Original Message ----- 
From: "Henri Yandell" <flamefew@gmail.com>
> I'm very tempted to try the branch then release strategy, and wondered
> what people thought about the idea. It might suggest a slight change
> to the version number style:
>
> Create 2.1 branch.
> Make changes to 2.1 branch until we're ready for release.
> Tag 2.1 branch with 2.1.0 tag.
> ... later
> Change 2.1 branch until we're ready for release
> Tag 2.1 branch with 2.1.1tag.
> ... later in parallel
> Change trunk until we're near a release
> Create 2.2 branch (or 3.0)
> Change 2.2 until ready
> Tag 2.2 with 2.2.0
>
> etc.
>
> If we called it 2.1-head or something, it wouldn't need the version
> change, it just feels more logical to go with a 2.1.0 release than a
> 2.1 one if we use this style of development.
>
> Anyway, it seems to me that this fits us more nowadays. We end up with
> the text package slowing down because it's not planned for the next
> release, and having to avoid various other bugzilla requests as
> they're not wanting to be fixed until later.
>
> Any thoughts?
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message