couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 16:48:32 GMT
FWIW, I don't think this isn't going to work for us.

I will post a full explanation later today when I have some free time.

On Fri, Oct 21, 2011 at 5:33 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

> On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting <jukka.zitting@gmail.com>
> wrote:
> > Hi,
> >
> > My 2c from the gallery. I'm not involved in CouchDB, so just making
> > general observations from the perspective of other Apache projects
> > interested in using Git.
> >
> > On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis <paul.joseph.davis@gmail.com>
> wrote:
> >> As Noah points out, there are ASF procedural issues that affect this
> >> discussion. Part of making a release involves getting community input
> >> on whether the release is a valid artefact. As such we need to be able
> >> to refer to these "not-release" sets of bytes.
> >
> > I'd say that's a perfectly valid use of tags. An official release
> > should be backed by a tag, but there's no requirement for the reverse.
> > Using tags for release candidates or other milestones should also be
> > fine. It should be up to each project to decide how they want to name
> > and manage tags.
> >
> > I also find the idea of renaming a release tag after the vote
> > completes a bit troublesome. The way I see it, a release manager will
> > tag a given state of the source tree and use that tag to build the
> > release candidate. After that no repository changes should be required
> > regardless of the result of the release vote. If the vote passes, the
> > candidate packages are pushed to www.apache.org/dist as-is. Otherwise
> > the release candidate is just dropped and the next one made.
> >
> > This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem.
> > If each release candidate is given a separate new tag and version
> > number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about
> > which build is being tested. Version numbers are cheap.
> >
> > BR,
> >
> > Jukka Zitting
> >
>
> Are there projects that do this version incrementing when a vote
> fails? That's an idea I haven't heard before.
>

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