commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [all] Release artifacts and RCs (was Re: Validator 1.3.1 Release)
Date Wed, 29 Nov 2006 03:30:48 GMT
On 11/28/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>
> On 11/28/06, Henri Yandell <flamefew@gmail.com> wrote:
> <snip/>
> >
> > We should:
> >
> > 1) SVN tag each RC.
> > 2) Put it up on in ~foo/component-version-rc1/
> > 3) Create files for the actual release - ie) don't put the rc1 in the
> > project.xml or any of the sites.
> <snap/>
>
> A side-effect of this is that the identity of the distro (whether it
> came from an RC or a release) is no longer in the artifact itself, but
> in the location where it is downloaded from.
>
> Given the advantage (to put it mildly) that the voted artifacts now
> become the released ones, that would probably have to do. I plan to do
> this for digester 1.8.


I think the potential confusion issue should be pretty limited ... we only
mention these things on the dev list, and (if we do things correctly) it'll
shortly be followed by a vote anyway.

Without real bits to vote on, it's really hard to provide proper oversight,
no matter how much you trust the RM (and I do :-), and the build process
being used.

-Rahul


Craig


> 4) Vote. If it passes then:
> > 4.1) Copy files to release locations.
> > 4.2) Copy the successful RC tag to the official tag.
> > 4.3) Deploy site.
> >
> > There is a problem with this - dates. If the date is in the release
> > then there are problems as you have to reroll the release to get the
> > date right. If it's just in the site then it's not a problem (ie:
> > changes.xml report) as the site isn't tied to the release vote - it
> > can go again 5 minutes later with the date applied.
> >
> > If the site is put in the release in lieu of documentation - no idea
> > (serves you right! - okay, so I don't like that style of documenting).
> >
> > Hen
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message