Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lang] release strategy
Date: Mon, 7 Feb 2005 18:36:13 -0500
Message-ID: <2B64219028BBFF48B3CC957EF10B58FE5D0068@ns1018.SSSI.seagull.nl>
Thread-Topic: [lang] release strategy
Thread-Index: AcUNYY2wyFTQw6wZTTqwDGs35fym0AADCpSQ
From: "Gary Gregory" <ggregory@seagullsoftware.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

Personally, I've always liked the following numbering scheme:=20

Major.Minor.Maintenance.

Gary

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]=20
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=20
2.1.0 or 2.1.1.

Stephen

----- Original Message -----=20
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
>=20


---------------------------------------------------------------------
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