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 -0000, 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]
