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 -0000, 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 -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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
