ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: [VOTE] Release ODE 1.1.1
Date Fri, 11 Jan 2008 16:13:45 GMT
On Jan 10, 2008 11:31 PM, Assaf Arkin <arkin@intalio.com> wrote:

> On 1/9/08, Matthieu Riou <matthieu@offthelip.org> wrote:
> >
> > There have been a few discussions on the legal-discuss mailing list
> about
> > the release process and building Release Candidates that are just
> rebuilt
> > to
> > make a final version when everybody is okay is more and more frowned
> upon
> > for diverse reasons.
>
>
> Digest for those of us not on legal-discuss?
>
> So as you'll see I'm now using the final version
> > numbers, I just name differently the directory in which I publish them.
> > Also
> > note that even though we publish binaries, the reference for any release
> > is
> > the source package. Binaries are just there for convenience.
>
>
> If the RC is good enough that we end cutting an official release, then I
> don't see a problem with that.  But if the RC needs fixing, then you might
> end up with two packages having the same name but different content, which
> is a problem.   Putting it in a different URL doesn't help much, once it
> hits my machine, it loses the source or origin and for all I know 1.1.1 is
> 1.1.1, whichever 1.1.1 it ends up being.
>

See something like (it all started on a discussion about the location of
LICENSE and NOTICE files):

http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200712.mbox/%3c802B7BC1-D956-45B3-B68B-CC89522FC606@gbiv.com%3e

Also:

> hyandell@gmail.com wrote on 2007-12-20 05:25:19 PM:
> > On Dec 20, 2007 1:48 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> > > On Dec 20, 2007, at 12:48 AM, Guillaume Nodet wrote:
> > >
> > > > PMCs can vote on a tag / branch by building the release from this
> > > > tag / branch and examine the artifacts generated to make sure they
> > > > are ok.  I don't see any problem with that.  Imho, it's up to the
> > > > PMC to choose between voting on binaries and voting on a tag.
> > >
> > > PMCs can vote on just about anything.  However, a release vote is on
> > > a packaged artifact containing the complete source code and signed
> > > by the release manager.  If you haven't voted on that, the PMC has
> > > not performed a valid release.
> > >
> > > Binaries are generated from release source packages. If the PMC is
> > > doing something else, then it has seriously screwed the pooch and
> > > may not even be releasing open source.
> >
> > There are four styles that I've seen referenced while on the board:
> >
> > 1) Voting on the intention. Someone then goes ahead and does the work
> > and releases. This is BAD.
> >
> > 2) Voting on the tag. Someone then goes ahead and does all the work
> > and releases. This is BAD.
> >
> > 3) Voting on an RC. This is a tag that has been built, voted on, and
> > then rebuilt to get the naming right in the filename/documentation.
> > This is increasingly frowned upon and I suspect is considered BAD now,
> > but I don't recall this being stated as policy anywhere.
> >
> > 4) Voting on the build itself. This is GOOD. Commons used to use 3)
> > and moved over to 4) six to twelve months ago.
> >
> > I suspect we need to be stating all this on
> > http://www.apache.org/dev/release.html. Currently the words 'vote' and
> > 'pmc' do not appear there.

Basically you vote on a signed source package which is directly what gets
published, with the same signature. If you vote on a RC and then I build
another release from the same tag to have the final release, anything can
happen in the middle (and it has). So the only way to keep the RC thing
would be to vote twice, once for the RC and another time when the final has
been built from the RC (which would be the real release vote). I find this
pretty annoying for several reasons.

So the arbitration is between:

   * the potential for a big release screwup
   * less convenience for developers, where you have to be careful where you
place each built package (but directories exist for a reason right?)

I'm open to other release processes but we can't work around the constraints
exposed by Roy.

Matthieu


> So -1 on releasing two versions with the same version number.
>
> Assaf
>
>
> With this in mind, I'm asking for a vote on the following distributions:
> >
> >
> >
> http://people.apache.org/~mriou/ode-1.1.1RC2/org/apache/ode/apache-ode-sources/1.1.1/apache-ode-sources-1.1.1.zip<http://people.apache.org/%7Emriou/ode-1.1.1RC2/org/apache/ode/apache-ode-sources/1.1.1/apache-ode-sources-1.1.1.zip>
> >
> >
> http://people.apache.org/~mriou/ode-1.1.1RC2/org/apache/ode/apache-ode-war/1.1.1/apache-ode-war-1.1.1.zip<http://people.apache.org/%7Emriou/ode-1.1.1RC2/org/apache/ode/apache-ode-war/1.1.1/apache-ode-war-1.1.1.zip>
> >
> >
> http://people.apache.org/~mriou/ode-1.1.1RC2/org/apache/ode/apache-ode-jbi/1.1.1/apache-ode-jbi-1.1.1.zip<http://people.apache.org/%7Emriou/ode-1.1.1RC2/org/apache/ode/apache-ode-jbi/1.1.1/apache-ode-jbi-1.1.1.zip>
> >
> > And here is my +1.
> >
> > Thanks,
> > Matthieu
> >
>

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