commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [lang] release strategy
Date Sun, 13 Feb 2005 04:20:33 GMT
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 <flamefew@gmail.com> 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 -0000, Stephen Colebourne
> <scolebourne@btopenworld.com> 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" <flamefew@gmail.com>
> > > Cool. I'll remove the xdocs from the branch.
> > >
> > > Hen
> > >
> > > On Sat, 12 Feb 2005 21:39:33 -0000, Stephen Colebourne
> > > <scolebourne@btopenworld.com> 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" <flamefew@gmail.com>
> > >> > 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 <flamefew@gmail.com>
> > >> > 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
> > >> >> <ggregory@seagullsoftware.com> wrote:
> > >> >> > Personally, I've always liked the following numbering scheme:
> > >> >> >
> > >> >> > Major.Minor.Maintenance.
> > >> >> >
> > >> >> > Gary
> > >> >> >
> > >> >> > -----Original Message-----
> > >> >> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > >> >> > 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" <flamefew@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
> > >> >> >
> > >> >> > ---------------------------------------------------------------------
> > >> >> > 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
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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
> > >
> >
> > ---------------------------------------------------------------------
> > 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


Mime
View raw message