Re: [lang] release strategy
This is why I ([collections]) use ant for builds and maven only for website building. Basically, IMHO, a src-zip should contain not only the source java, but the source for building a local copy of the website. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Pretty sure Maven doesn't put xdocs in the src zip. If we have to do this, then I think we shouldn't branch for a release, it's going to be too painful to keep the two sites synced. Starting to see negatives to the tying of site to code that Maven does :) Hen On Sun, 13 Feb 2005 01:51:52 -, Stephen Colebourne [EMAIL PROTECTED] wrote: Er, no. The xdocs should be shipped in the src zip file. They are used by people outside Apache building a website. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Cool. I'll remove the xdocs from the branch. Hen On Sat, 12 Feb 2005 21:39:33 -, Stephen Colebourne [EMAIL PROTECTED] wrote: It needs to be like [collections], but probably not as automated Website is built from trunk. Javadoc of 2.1 release is built from 2.1 branch and copied to server in apidocs-2.1 directory Hyperlink of 2.1 javadoc is inserted into navigation.xml of trunk Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Though now I'm a bit confused about whether the website should exist on the 2.1 branch or not :) Odd as it sounds, I think we should we be releasing code from 2.1 branch, and building the site from trunk. Otherwise it'll be a bit odd I think. Sound insane? Hen On Sat, 12 Feb 2005 15:22:08 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Only question is whether to specify a 0 for the 0th maintenance. Not a big deal though, I've setup the following release branch: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH the naming matches the syntax we used for 1.0 when making 1.0.1. I know it could be a lot better (especially as SVN doesn't barf on . as CVS does), but I'm going with consistency for the moment. I'll start tweaking that towards a release. Trunk is 2.2-dev now. Hen On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory [EMAIL PROTECTED] wrote: Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [lang] release strategy
Stephen Colebourne wrote:
This is why I ([collections]) use ant for builds and maven only for
website building.
Basically, IMHO, a src-zip should contain not only the source java, but
the source for building a local copy of the website.
I agree (that the xdoc should be included in the src distro). This
could be done using a maven preGoal:
preGoal name=dist:build-src
ant:copy todir=${maven.dist.src.assembly.dir}/xdocs
ant:fileset dir=xdocs/
/ant:copy
/preGoal
I don't see this as a big maintenance issue, but could be I am missing
Hen's point below.
Phil
Stephen
- Original Message - From: Henri Yandell [EMAIL PROTECTED]
Pretty sure Maven doesn't put xdocs in the src zip. If we have to do
this, then I think we shouldn't branch for a release, it's going to be
too painful to keep the two sites synced.
Starting to see negatives to the tying of site to code that Maven does :)
Hen
On Sun, 13 Feb 2005 01:51:52 -, Stephen Colebourne
[EMAIL PROTECTED] wrote:
Er, no.
The xdocs should be shipped in the src zip file. They are used by people
outside Apache building a website.
Stephen
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
Cool. I'll remove the xdocs from the branch.
Hen
On Sat, 12 Feb 2005 21:39:33 -, Stephen Colebourne
[EMAIL PROTECTED] wrote:
It needs to be like [collections], but probably not as automated
Website is built from trunk.
Javadoc of 2.1 release is built from 2.1 branch and copied to
server in
apidocs-2.1 directory
Hyperlink of 2.1 javadoc is inserted into navigation.xml of trunk
Stephen
- Original Message -
From: Henri Yandell [EMAIL PROTECTED]
Though now I'm a bit confused about whether the website should
exist
on the 2.1 branch or not :)
Odd as it sounds, I think we should we be releasing code from 2.1
branch, and building the site from trunk.
Otherwise it'll be a bit odd I think. Sound insane?
Hen
On Sat, 12 Feb 2005 15:22:08 -0500, Henri Yandell
[EMAIL PROTECTED]
wrote:
Only question is whether to specify a 0 for the 0th
maintenance. Not
a big deal though, I've setup the following release branch:
https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH
the naming matches the syntax we used for 1.0 when making 1.0.1. I
know it could be a lot better (especially as SVN doesn't barf
on . as
CVS does), but I'm going with consistency for the moment.
I'll start tweaking that towards a release. Trunk is 2.2-dev now.
Hen
On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory
[EMAIL PROTECTED] wrote:
Personally, I've always liked the following numbering scheme:
Major.Minor.Maintenance.
Gary
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] release strategy
On Sun, 13 Feb 2005 10:05:36 -0500, Phil Steitz [EMAIL PROTECTED] wrote:
Stephen Colebourne wrote:
This is why I ([collections]) use ant for builds and maven only for
website building.
Basically, IMHO, a src-zip should contain not only the source java, but
the source for building a local copy of the website.
I agree (that the xdoc should be included in the src distro). This
could be done using a maven preGoal:
preGoal name=dist:build-src
ant:copy todir=${maven.dist.src.assembly.dir}/xdocs
ant:fileset dir=xdocs/
/ant:copy
/preGoal
On this particular issue, I think the documentation should be included
with the build and not the site. Even more importantly for Collections
than for Lang; a Collections 2.1 downloader should not get lots of
Collections 3.0 stuff.
We don't separate documentation and site though, so I'm -0 for the
xdocs being in there and will add them in, it just changes the release
strategy.
I don't see this as a big maintenance issue, but could be I am missing
Hen's point below.
If we branch off and do a release from a branch, we have to maintain
the branch's site for the release and the trunk's site for our live
site. So our previous release strategy makes more sense under this
scenario, release from trunk and then tag at the release point.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] release strategy
I get it now -- both points. Need to think about how to separate the docs site gen. Phil Henri Yandell wrote: On this particular issue, I think the documentation should be included with the build and not the site. Even more importantly for Collections than for Lang; a Collections 2.1 downloader should not get lots of Collections 3.0 stuff. We don't separate documentation and site though, so I'm -0 for the xdocs being in there and will add them in, it just changes the release strategy. I don't see this as a big maintenance issue, but could be I am missing Hen's point below. If we branch off and do a release from a branch, we have to maintain the branch's site for the release and the trunk's site for our live site. So our previous release strategy makes more sense under this scenario, release from trunk and then tag at the release point. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] release strategy
In the long term, yeah. In the short term I'll just do this the old way :) Hen On Sun, 13 Feb 2005 10:50:32 -0500, Phil Steitz [EMAIL PROTECTED] wrote: I get it now -- both points. Need to think about how to separate the docs site gen. Phil Henri Yandell wrote: On this particular issue, I think the documentation should be included with the build and not the site. Even more importantly for Collections than for Lang; a Collections 2.1 downloader should not get lots of Collections 3.0 stuff. We don't separate documentation and site though, so I'm -0 for the xdocs being in there and will add them in, it just changes the release strategy. I don't see this as a big maintenance issue, but could be I am missing Hen's point below. If we branch off and do a release from a branch, we have to maintain the branch's site for the release and the trunk's site for our live site. So our previous release strategy makes more sense under this scenario, release from trunk and then tag at the release point. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] release strategy
Only question is whether to specify a 0 for the 0th maintenance. Not a big deal though, I've setup the following release branch: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH the naming matches the syntax we used for 1.0 when making 1.0.1. I know it could be a lot better (especially as SVN doesn't barf on . as CVS does), but I'm going with consistency for the moment. I'll start tweaking that towards a release. Trunk is 2.2-dev now. Hen On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory [EMAIL PROTECTED] wrote: Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] release strategy
Though now I'm a bit confused about whether the website should exist on the 2.1 branch or not :) Odd as it sounds, I think we should we be releasing code from 2.1 branch, and building the site from trunk. Otherwise it'll be a bit odd I think. Sound insane? Hen On Sat, 12 Feb 2005 15:22:08 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Only question is whether to specify a 0 for the 0th maintenance. Not a big deal though, I've setup the following release branch: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH the naming matches the syntax we used for 1.0 when making 1.0.1. I know it could be a lot better (especially as SVN doesn't barf on . as CVS does), but I'm going with consistency for the moment. I'll start tweaking that towards a release. Trunk is 2.2-dev now. Hen On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory [EMAIL PROTECTED] wrote: Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] release strategy
It needs to be like [collections], but probably not as automated Website is built from trunk. Javadoc of 2.1 release is built from 2.1 branch and copied to server in apidocs-2.1 directory Hyperlink of 2.1 javadoc is inserted into navigation.xml of trunk Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Though now I'm a bit confused about whether the website should exist on the 2.1 branch or not :) Odd as it sounds, I think we should we be releasing code from 2.1 branch, and building the site from trunk. Otherwise it'll be a bit odd I think. Sound insane? Hen On Sat, 12 Feb 2005 15:22:08 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Only question is whether to specify a 0 for the 0th maintenance. Not a big deal though, I've setup the following release branch: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH the naming matches the syntax we used for 1.0 when making 1.0.1. I know it could be a lot better (especially as SVN doesn't barf on . as CVS does), but I'm going with consistency for the moment. I'll start tweaking that towards a release. Trunk is 2.2-dev now. Hen On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory [EMAIL PROTECTED] wrote: Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] release strategy
Cool. I'll remove the xdocs from the branch. Hen On Sat, 12 Feb 2005 21:39:33 -, Stephen Colebourne [EMAIL PROTECTED] wrote: It needs to be like [collections], but probably not as automated Website is built from trunk. Javadoc of 2.1 release is built from 2.1 branch and copied to server in apidocs-2.1 directory Hyperlink of 2.1 javadoc is inserted into navigation.xml of trunk Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Though now I'm a bit confused about whether the website should exist on the 2.1 branch or not :) Odd as it sounds, I think we should we be releasing code from 2.1 branch, and building the site from trunk. Otherwise it'll be a bit odd I think. Sound insane? Hen On Sat, 12 Feb 2005 15:22:08 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Only question is whether to specify a 0 for the 0th maintenance. Not a big deal though, I've setup the following release branch: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH the naming matches the syntax we used for 1.0 when making 1.0.1. I know it could be a lot better (especially as SVN doesn't barf on . as CVS does), but I'm going with consistency for the moment. I'll start tweaking that towards a release. Trunk is 2.2-dev now. Hen On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory [EMAIL PROTECTED] wrote: Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] release strategy
Er, no. The xdocs should be shipped in the src zip file. They are used by people outside Apache building a website. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Cool. I'll remove the xdocs from the branch. Hen On Sat, 12 Feb 2005 21:39:33 -, Stephen Colebourne [EMAIL PROTECTED] wrote: It needs to be like [collections], but probably not as automated Website is built from trunk. Javadoc of 2.1 release is built from 2.1 branch and copied to server in apidocs-2.1 directory Hyperlink of 2.1 javadoc is inserted into navigation.xml of trunk Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Though now I'm a bit confused about whether the website should exist on the 2.1 branch or not :) Odd as it sounds, I think we should we be releasing code from 2.1 branch, and building the site from trunk. Otherwise it'll be a bit odd I think. Sound insane? Hen On Sat, 12 Feb 2005 15:22:08 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Only question is whether to specify a 0 for the 0th maintenance. Not a big deal though, I've setup the following release branch: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH the naming matches the syntax we used for 1.0 when making 1.0.1. I know it could be a lot better (especially as SVN doesn't barf on . as CVS does), but I'm going with consistency for the moment. I'll start tweaking that towards a release. Trunk is 2.2-dev now. Hen On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory [EMAIL PROTECTED] wrote: Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] release strategy
Pretty sure Maven doesn't put xdocs in the src zip. If we have to do this, then I think we shouldn't branch for a release, it's going to be too painful to keep the two sites synced. Starting to see negatives to the tying of site to code that Maven does :) Hen On Sun, 13 Feb 2005 01:51:52 -, Stephen Colebourne [EMAIL PROTECTED] wrote: Er, no. The xdocs should be shipped in the src zip file. They are used by people outside Apache building a website. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Cool. I'll remove the xdocs from the branch. Hen On Sat, 12 Feb 2005 21:39:33 -, Stephen Colebourne [EMAIL PROTECTED] wrote: It needs to be like [collections], but probably not as automated Website is built from trunk. Javadoc of 2.1 release is built from 2.1 branch and copied to server in apidocs-2.1 directory Hyperlink of 2.1 javadoc is inserted into navigation.xml of trunk Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Though now I'm a bit confused about whether the website should exist on the 2.1 branch or not :) Odd as it sounds, I think we should we be releasing code from 2.1 branch, and building the site from trunk. Otherwise it'll be a bit odd I think. Sound insane? Hen On Sat, 12 Feb 2005 15:22:08 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Only question is whether to specify a 0 for the 0th maintenance. Not a big deal though, I've setup the following release branch: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH the naming matches the syntax we used for 1.0 when making 1.0.1. I know it could be a lot better (especially as SVN doesn't barf on . as CVS does), but I'm going with consistency for the moment. I'll start tweaking that towards a release. Trunk is 2.2-dev now. Hen On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory [EMAIL PROTECTED] wrote: Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe
Re: [lang] release strategy
I'm thinking that the following covers all the necessaries: 2.1 release 1) Figure out release notes. Use svn log + wiki to see if anything is missing. 2) Build a dist, jar and site as release candidate 3) JDiff 4) Deal with issues 5) Vote 6) Release, tag, mirror, update-site, repository etc. Did I miss anything? Hen On Sat, 12 Feb 2005 21:21:50 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Pretty sure Maven doesn't put xdocs in the src zip. If we have to do this, then I think we shouldn't branch for a release, it's going to be too painful to keep the two sites synced. Starting to see negatives to the tying of site to code that Maven does :) Hen On Sun, 13 Feb 2005 01:51:52 -, Stephen Colebourne [EMAIL PROTECTED] wrote: Er, no. The xdocs should be shipped in the src zip file. They are used by people outside Apache building a website. Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Cool. I'll remove the xdocs from the branch. Hen On Sat, 12 Feb 2005 21:39:33 -, Stephen Colebourne [EMAIL PROTECTED] wrote: It needs to be like [collections], but probably not as automated Website is built from trunk. Javadoc of 2.1 release is built from 2.1 branch and copied to server in apidocs-2.1 directory Hyperlink of 2.1 javadoc is inserted into navigation.xml of trunk Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Though now I'm a bit confused about whether the website should exist on the 2.1 branch or not :) Odd as it sounds, I think we should we be releasing code from 2.1 branch, and building the site from trunk. Otherwise it'll be a bit odd I think. Sound insane? Hen On Sat, 12 Feb 2005 15:22:08 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Only question is whether to specify a 0 for the 0th maintenance. Not a big deal though, I've setup the following release branch: https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LANG_2_1_BRANCH the naming matches the syntax we used for 1.0 when making 1.0.1. I know it could be a lot better (especially as SVN doesn't barf on . as CVS does), but I'm going with consistency for the moment. I'll start tweaking that towards a release. Trunk is 2.2-dev now. Hen On Mon, 7 Feb 2005 18:36:13 -0500, Gary Gregory [EMAIL PROTECTED] wrote: Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] release strategy
Personally, I've always liked the following numbering scheme: Major.Minor.Maintenance. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] release strategy
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
