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]
