incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1
Date Sat, 21 May 2011 04:30:49 GMT
On Fri, May 20, 2011 at 06:30:52PM -0700, Mattmann, Chris A (388J) wrote:
> Hmmm....Sorry but this is the first time I've carefully looked at the
> ReleaseGuide, otherwise if I saw it back when you threw it up on the wiki,
> I'd probably have debated this convention for *artifact names* (note this an
> important distinction -- I'm not debating the programmatic use of version #s
> as is covered below). 

The thing I really care about is the inclusion of all three numbers X.Y.Z in
the artifact names.

For technical reasons documented in that thread, it's essential that the
downstream CPAN artifacts use X.Y.Z consistently.  It strikes me as a bad idea
to have the Apache canonical artifacts sometimes use X.Y and sometimes use
X.Y.Z, sometimes matching downstream and sometimes not.

The version number for this release is either "0.1.0" or "0.1.0-incubating".
It is not "0.1" or "0.1-incubating", because Z is definitely defined as "0".

I should have gone out of my way to fix all usages of "0.1-incubating", such
as in JIRA.  Confusion is understandable, because even though that thread
concludes with a firm decision to use X.Y.Z numbering consistently, we did not
aggressively apply that decision in every nook and cranny or jump up and down
screaming every time somebody subsequently omitted Z.

> Most of the Apache releases I've seen use *artifact names* likes:
> apache-<product>-<version>-<src|bin>.<ext>

The inclusion of "src" wasn't something I considered.  For what it's worth, we
are unlikely to do "bin" releases for Lucy any time soon, because what with
natively compiled code and multiple binding language targets there are so many
possible configurations.  So, I don't know that it's important to include
"src" to differentiate from "bin" releases that may never exist, but it's not
something I have a concrete reason to oppose.
The placement of the word "incubating" follows the Incubator documentation.

    The release name should contain the podling name and may contain apache.
    Incubator policy insists that it must also contain 'incubating' (though
    small variations for the sake of readability are usually acceptable). 

    For example, for podling foo, both 'apache-foo-incubating' and
    'foo-incubating' would be acceptable names. 

However, that was not discussed on the Lucy dev list -- it's something I
discovered and revised while distilling down the ReleaseGuide.

I happen to prefer attaching "incubating" to "apache-lucy" rather than the
version number because no code or metadata includes the word "incubating" in
the version number.  However, either way meets the requirements of the
Incubator.  It's more important to me that once we choose one of these
conventions, we use it consistently for as long as we are in the Incubator.

> >    // Actual name
> >
> >    // Documented in ReleaseGuide
> >
> Gotcha. I transposed the branch and tag names.
> Speaking of which though, let me also poke at this. Having 2 conventions for
> tags and branches seems odd to me and it seems like the introduction of
> pointless complexity for little gain. Why not just pick one:
> either:
> apache-lucy-X.Y (e.g., apache-lucy-0.1-incubating)
> or:
> X.Y (e.g., 0.1-incubating)
> Having 2 conventions for branches and tags seems odd to me. 

This branch naming convention was adopted after studying Lucene's branches:

> > And there is no tag for the RC as the instructions set out:
> > 
> >
> IMO and experience, tags are created when a release VOTE passes to capture a
> *final* snapshot of the release that's not expected to change. Some other
> projects use tags as the first release VOTE'ing artifact, and then roll a
> branch when the VOTE passes to indicate further development in a series.
> Either way is fine. I'm happy to create the tag, but honestly, this approach
> seems like an RM decision to me and something that we should leave open to
> the guy picking up a shovel and doing the RM'ing.

The end goal of the release tagging procedure is a tag associated with the
final artifacts.  I don't really care how we get there.  The recipe is there
so that future RMs will get to the end goal consistently and not screw up the
tag-to-release-artifacts association.  It was inspired by someone else's
routine -- don't remember whether I got it from Incubator docs, somebody other
TLP's release procedures, or mailing list spelunking.

Marvin Humphrey

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message