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)
Message-ID: <002301c50d61$773d6bf0$95cf9a51@SCOLEBOURNE>
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <31cc373605020616525e8b5d30@mail.gmail.com>
Subject: Re: [lang] release strategy
Date: Mon, 7 Feb 2005 22:07:50 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

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