RM docs are always guides, not decrees, but Marvin is certainly within his rights to vote according to the current docs. Keep in mind noone gets to veto a release (unless it's on legal grounds, and those should be rare).
FWIW, I think the full 3-part version string belongs in the package name, while the 2-part version string belongs in the branch, as that is the point of creating the branch in the first place- so you can cut maintainence releases from it that are just patch-level changes. Unfortunately CPAN won't be very happy about it, but it's a manageable problem. The tag issue for rc's I am ambivalent about personally. But basically I agree with the existing Lucy docs. In the interest of time, since I know you don't have much more you can spare on this effort, I suggest you try to just follow them as-is. And lets keep the initial voting confined to dev@lucy as Marvin suggests. ----- Original Message ---- > From: "Mattmann, Chris A (388J)" <[email protected]> > To: "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]>; >"[email protected]" <[email protected]> > Sent: Fri, May 20, 2011 9:30:52 PM > Subject: Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate >#1 > > 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: > >> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/ > > > > 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: > > apache-<product>-<version>-<src|bin>.<ext> > > 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: > > apache-<product>-incubating-<version>.<ext> > > > > > 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: <http://s.apache.org/lW>. > > > > The branch we will use for bugfixes is also misnamed: > > > > // Actual name > > >https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/ > > > // Documented in ReleaseGuide > > https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y > > 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. > > > > > And there is no tag for the RC as the instructions set out: > > > > >https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN > > > 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. > > Cheers, > Chris > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: [email protected] > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >
