Okey dokey, in the interest of just getting the RC out and moving onto the next set of things to get done, RC 2 coming up...
Cheers, Chris On May 20, 2011, at 6:43 PM, Joe Schaefer wrote: > 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 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
