[lang] release strategy

[Henri Yandell <fl...@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

Re: [lang] release strategy

[Stephen Colebourne <sc...@btopenworld.com>]

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" <fl...@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