incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1
Date Sat, 21 May 2011 01:30:52 GMT
Hi Marvin,

On May 20, 2011, at 2:44 PM, Marvin Humphrey wrote:

> Hi, Chris, thanks for expediting.
> On Fri, May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
> The artifacts here do not follow the version naming convention that is used by
> the source code of X.Y.Z, and that the ReleaseGuide specifies the artifacts
> should use:
>    apache-lucy-0.1-incubating-src.tar.gz   //  actual name
>    apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in ReleaseGuide.

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). Most of the Apache releases I've seen use *artifact
names* likes:


In this case, we're the lucy product, version 0.1-incubating, it's a src release, and it's
a tar.gz extension.

I think that makes more sense than:


> It's essential that our artifacts match the actual version number strings.

Who are you talking about when you say "our"? I am included in that set? If so, I'm not necessarily
on board with your proposal for what the *artfiact name* should be. Note that the discussion
we had on your referenced thread below is actually talking about programmatic uses of a string/int/number
version within the context of PL-specific forges like CPAN/Maven Central/PyPI/etc. It's not
talking about artifact names.

> This was hammered out over a long thread here: <>.
> The branch we will use for bugfixes is also misnamed:
>    // 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:


apache-lucy-X.Y (e.g., apache-lucy-0.1-incubating)


X.Y (e.g., 0.1-incubating)

Having 2 conventions for branches and tags seems odd to me. 

> 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.

> I regret that I must vote -1.  Please change the name of the tag, following
> the documentation in the ReleaseGuide precisely and reroll.  If you disagree
> with anything you encounter, please raise your concern on the dev list.

No probs. Concerns raised above. 


Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

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

View raw message