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: domain of flamefew@gmail.com designates
 64.233.170.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding;
        b=PfsCrnfeyDs/Etimm9OZFDCgUUiSebAw7T/u/vWop5KVTXH0myXSj9qsPUhri2jRddHd7YR3PNj2NQQqESIuoUHT+WbKg+fgBBbGjmvsJvaqnHkLki7cTthtS4lAMGV1BHk3+9B5eMWIjZzmR50ZtsWtydIDm1K98VjwPMdLVPc=
Message-ID: <31cc373605020616525e8b5d30@mail.gmail.com>
Date: Sun, 6 Feb 2005 19:52:58 -0500
From: Henri Yandell <flamefew@gmail.com>
Reply-To: Henri Yandell <flamefew@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: [lang] release strategy
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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