You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2011/08/28 22:24:44 UTC
[lucy-dev] TRIAL CPAN releases
On Thu, Aug 18, 2011 at 01:40:11PM -0500, Peter Karman wrote:
> Chris Hostetter wrote on 08/18/2011 01:32 PM:
>
> > Alternately: Apache Lucy could continue to opperate
> > exactly as was done with 0.2.0 and 0.2.1, but the guidelines for
> > downstream packagers could encourage them to initially package every RC as
> > an "unstable/beta" to smoke out any distribution channel specific problems
> > first before they break other pacakges that depend on Lucy.
>
> That was my first thought in response to this thread: always release a
> new Apache Lucy release to CPAN as an unstable release initially, wait a
> few days, then check smoketesters and re-release as stable release with
> official version number.
On #lucy_dev on Friday, David Wheeler invited Ricardo Signes
(<http://search.cpan.org/~rjbs/>) to stop by. Ricardo maintains some of the
relevant PAUSE/CPAN code, and he was able to help with the mechanics of
dev-only versions.
It used to be that the only way to get a tarball into the CPAN distribution
channel without it becoming the authoritative release was to supply a file
with an underscore in the version number:
http://pause.perl.org/pause/query?ACTION=pause_04about#conventions
The automatic integration of your work into several indexes and directory
trees is not always what you desire. Often you want to release code for
testing out the next release. Code that propagates through CPAN but is not
in a stable state. Something between two versions.
If you want to do that simply choose a filename that matches /\d\.\d+_\d/.
However, there is now another option: add "TRIAL" to the filename. This has
been used for a while by some other distros, such as Moose...
http://search.cpan.org/~doy/Moose-2.0102-TRIAL/
... and now, it seems, will become part of the official documentation:
https://github.com/rjbs/pause/commit/8828bfba15fb1a1921ae286f417900f257fd9a76
The general recommendation is that you not reuse version numbers even with
TRIAL, because an official release with the same version number minus "-TRIAL"
will not displace the TRIAL version of the module in someone's installation.
However, it seems to me that it would be OK for us to release an official CPAN
version of Lucy if it differs from -TRIAL only in the version number.
This would be our workflow for 0.3.0:
* Make canonical Apache release of Lucy 0.3.0.
* Upload Lucy-0.3.0-TRIAL.tar.gz to CPAN.
* If CPAN testers comes back clean, upload Lucy-0.3.0.tar.gz to CPAN.
* If CPAN testers reveals flaws, spin a canonical ASF release of Lucy
0.3.1, then upload Lucy-0.3.1-TRIAL.tar.gz to CPAN.
* Continue as necessary with canonical ASF releases and -TRIAL CPAN
releases until we're good.
The iteration may take a while, but that's OK. The important thing is to
avoid breaking any distributions that rely on Lucy as a dependency, and this
scheme achieves that.
Marvin Humphrey
Re: [lucy-dev] TRIAL CPAN releases
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Aug 30, 2011 at 09:18:50AM -0700, Chris Hostetter wrote:
>
> : If we are comfortable with distributing RC materials outside of Apache
> : channels, then yes. I'm not clear on that. Have other ASF projects done
> : something similar? If nobody knows, perhaps we might ask on general@incubator?
>
> I agree that asking on general@incubator would be a good idea to get more
> perspective.
The server which serves the results pages for CPAN Testers went down today.
http://markmail.org/message/wxgczkf63x7dji55
The CPAN Testers Metabase server (which *collects* reports) is still
working as usual and collecting reports, so submissions will not be lost,
but with the main server wedged, there will be a delay before they are
"visible" to the community.
I've been working up a draft destined for general@incubator, but I'm going to
hold off on sending until <http://www.cpantesters.org/distro/L/Lucy.html> is
back up so that incubator peeps who aren't familiar with CPAN testers will be
able to see for themselves what a great resource it is.
Marvin Humphrey
Re: [lucy-dev] TRIAL CPAN releases
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Not to belabor this discussion, but:
On Aug 30, 2011, at 10:23 AM, Chris Hostetter wrote:
> : > My own opinion is that even if the PMC were to do it "officially" then it
> : > wouldn't be much different then PMCs that publish maven SNAPSHOT builds to
> : > ibiblio (and in the ways that it is different it's better because it would
> : > only be RCs under formal vote)
> :
> : This doesn't really happen anymore as I understand it. Folks who want to do this
> : go to http://repository.apache.org/ and then upload their artifacts to the Nexus
> : server there, and then when the RC is released, and then closed, the released RC
> : gets sync'ed to Maven Central at some specified interval. So even these releases
> : go through Apache still.
>
> ok .. so it's repository.apache.org instead of ibiblio -- but the point is
> still the same: unofficial builds (which are clearly identified as
> unofficial) are distributed using langauge specific mechanisms for
> the purposes of user testing.
Right, they are decidedly "unofficial" as far as the ASF is concerned, but not as far as
downstream consumers who may never download a build from the ASF, but
will get it via Maven are concerned.
> The fact that maven is an apache project
> so that language specific mechanism happens to be an apache.org server
> doesn't really seem relevant to the point...
>
> https://maven.apache.org/guides/development/guide-testing-development-plugins.html
>
> ...and in any case, those are trunk snapshots, and we're talking about
> release candidates.
The *same* process for repository.apache.org for snapshots exists
for RCs.
> the point of release candiates is to be tested by end
> users before the release becomes official, so i can't see any objection to
> making end-products produced from those release candidates (clearly labled
> as such) available for users who are interested in testing them via the
> channel that they would normally use.
Nominally I agree with you but I know there is a set of others at the ASF
that don't, e.g., sebb to name one. Anyways, I'll drop it.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] TRIAL CPAN releases
Posted by Chris Hostetter <ho...@fucit.org>.
: > My own opinion is that even if the PMC were to do it "officially" then it
: > wouldn't be much different then PMCs that publish maven SNAPSHOT builds to
: > ibiblio (and in the ways that it is different it's better because it would
: > only be RCs under formal vote)
:
: This doesn't really happen anymore as I understand it. Folks who want to do this
: go to http://repository.apache.org/ and then upload their artifacts to the Nexus
: server there, and then when the RC is released, and then closed, the released RC
: gets sync'ed to Maven Central at some specified interval. So even these releases
: go through Apache still.
ok .. so it's repository.apache.org instead of ibiblio -- but the point is
still the same: unofficial builds (which are clearly identified as
unofficial) are distributed using langauge specific mechanisms for
the purposes of user testing. The fact that maven is an apache project
so that language specific mechanism happens to be an apache.org server
doesn't really seem relevant to the point...
https://maven.apache.org/guides/development/guide-testing-development-plugins.html
...and in any case, those are trunk snapshots, and we're talking about
release candidates. the point of release candiates is to be tested by end
users before the release becomes official, so i can't see any objection to
making end-products produced from those release candidates (clearly labled
as such) available for users who are interested in testing them via the
channel that they would normally use.
-Hoss
Re: [lucy-dev] TRIAL CPAN releases
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Guys,
On Aug 30, 2011, at 9:18 AM, Chris Hostetter wrote:
>
> : If we are comfortable with distributing RC materials outside of Apache
> : channels, then yes. I'm not clear on that. Have other ASF projects done
> : something similar? If nobody knows, perhaps we might ask on general@incubator?
>
> I agree that asking on general@incubator would be a good idea to get more
> perspective.
+1.
>
> My own opinion is that even if the PMC were to do it "officially" then it
> wouldn't be much different then PMCs that publish maven SNAPSHOT builds to
> ibiblio (and in the ways that it is different it's better because it would
> only be RCs under formal vote)
This doesn't really happen anymore as I understand it. Folks who want to do this
go to http://repository.apache.org/ and then upload their artifacts to the Nexus
server there, and then when the RC is released, and then closed, the released RC
gets sync'ed to Maven Central at some specified interval. So even these releases
go through Apache still.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] TRIAL CPAN releases
Posted by Chris Hostetter <ho...@fucit.org>.
: If we are comfortable with distributing RC materials outside of Apache
: channels, then yes. I'm not clear on that. Have other ASF projects done
: something similar? If nobody knows, perhaps we might ask on general@incubator?
I agree that asking on general@incubator would be a good idea to get more
perspective.
My own opinion is that even if the PMC were to do it "officially" then it
wouldn't be much different then PMCs that publish maven SNAPSHOT builds to
ibiblio (and in the ways that it is different it's better because it would
only be RCs under formal vote)
But this doesn't have to be anything "official" by the PMC ... the RM/PMC
put up a Source RC for people to test -- part of the testing that some
third party person (or a community member wearing a diff hat) can do is to
use that Source RC to generate a langauge specific dist and upload that
dist to a repo like CPAN (clearly labeled as an unofficial RC/beta build)
-- and that should be totally fine.
if "TRIAL" is the CPAN specific way of clearly labeling things as
unofficial, then so be it.
-Hoss
Re: [lucy-dev] TRIAL CPAN releases
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Aug 30, 2011 at 01:43:45AM +0000, bch@methodlogic.net wrote:
> > BTW, I verified that "TRIAL1" (with the added "1") will work against the
> > current PAUSE code. All that matters is that the filename contain the string
> > "TRIAL" (i.e. Lucy-0.3.0-ATRIAL-FIBRILLATION.tar.gz would work, too):
>
> Is that part of the spec., or are you taking advantage of buggy behaviour?
It's part of the documentation -- "spec" might be a strong word. ;)
http://pause.perl.org/pause/query?ACTION=pause_04about#conventions
If you want to do that simply choose a filename that matches /\d\.\d+_\d/
or contains TRIAL.
I think we're OK, because these tarballs will be short-lived. In a worst-case
scenario, the PAUSE behavior changes without us knowing and a TRIAL tarball
accidentally becomes official as far as CPAN goes. We could repair that with
either an X.Y.Z.1 CPAN-only release or a new canonical ASF bugfix release.
Marvin Humphrey
Re: [lucy-dev] TRIAL CPAN releases
Posted by bc...@methodlogic.net.
On Mon, Aug 29, 2011 at 05:42:45PM -0700, Marvin Humphrey wrote:
> On Mon, Aug 29, 2011 at 02:56:11PM -0700, Chris Hostetter wrote:
> > Hmmm.... wouldn't it be better to take advantage of uplodaing -TRIAL
> > packages earlier in the release process?
> >
> > * make RC1 of Lucy 0.3.0 (RM)
> > * Upload Lucy-0.3.0-TRIAL1.tar.gz to CPAN. (CPAN packager)
> > * If CPAN testers reveals flaws in -TRIAL pacakge, consider that when voting on RC1 (PMC)
> > * Repeat from top as new RCs are produced (RM)
> > * If vote passes re-upload final RC as Lucy-0.3.0.tar.gz (CPAN packager)
>
> If we are comfortable with distributing RC materials outside of Apache
> channels, then yes. I'm not clear on that. Have other ASF projects done
> something similar? If nobody knows, perhaps we might ask on general@incubator?
>
> BTW, I verified that "TRIAL1" (with the added "1") will work against the
> current PAUSE code. All that matters is that the filename contain the string
> "TRIAL" (i.e. Lucy-0.3.0-ATRIAL-FIBRILLATION.tar.gz would work, too):
Is that part of the spec., or are you taking advantage of buggy behaviour?
> https://github.com/rjbs/pause/blob/8828bfba15fb1a1921ae286f417900f257fd9a76/lib/PAUSE/dist.pm#L253
>
> if (
> $dist =~ /\d\.\d+_\d/
> ||
> $dist =~ /TRIAL/
> ||
> $dist =~ m|/perl-\d+\.\d+\.\d+-RC\d+\.|x
> ) {
>
> Marvin Humphrey
>
--
Brad Harder
Method Logic Digital Consulting
http://methodlogic.net/
http://twitter.com/bcharder
Re: [lucy-dev] TRIAL CPAN releases
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Aug 29, 2011 at 02:56:11PM -0700, Chris Hostetter wrote:
> Hmmm.... wouldn't it be better to take advantage of uplodaing -TRIAL
> packages earlier in the release process?
>
> * make RC1 of Lucy 0.3.0 (RM)
> * Upload Lucy-0.3.0-TRIAL1.tar.gz to CPAN. (CPAN packager)
> * If CPAN testers reveals flaws in -TRIAL pacakge, consider that when voting on RC1 (PMC)
> * Repeat from top as new RCs are produced (RM)
> * If vote passes re-upload final RC as Lucy-0.3.0.tar.gz (CPAN packager)
If we are comfortable with distributing RC materials outside of Apache
channels, then yes. I'm not clear on that. Have other ASF projects done
something similar? If nobody knows, perhaps we might ask on general@incubator?
BTW, I verified that "TRIAL1" (with the added "1") will work against the
current PAUSE code. All that matters is that the filename contain the string
"TRIAL" (i.e. Lucy-0.3.0-ATRIAL-FIBRILLATION.tar.gz would work, too):
https://github.com/rjbs/pause/blob/8828bfba15fb1a1921ae286f417900f257fd9a76/lib/PAUSE/dist.pm#L253
if (
$dist =~ /\d\.\d+_\d/
||
$dist =~ /TRIAL/
||
$dist =~ m|/perl-\d+\.\d+\.\d+-RC\d+\.|x
) {
Marvin Humphrey
Re: [lucy-dev] TRIAL CPAN releases
Posted by Chris Hostetter <ho...@fucit.org>.
: The general recommendation is that you not reuse version numbers even with
: TRIAL, because an official release with the same version number minus "-TRIAL"
: will not displace the TRIAL version of the module in someone's installation.
: However, it seems to me that it would be OK for us to release an official CPAN
: version of Lucy if it differs from -TRIAL only in the version number.
:
: This would be our workflow for 0.3.0:
:
: * Make canonical Apache release of Lucy 0.3.0.
: * Upload Lucy-0.3.0-TRIAL.tar.gz to CPAN.
: * If CPAN testers comes back clean, upload Lucy-0.3.0.tar.gz to CPAN.
: * If CPAN testers reveals flaws, spin a canonical ASF release of Lucy
: 0.3.1, then upload Lucy-0.3.1-TRIAL.tar.gz to CPAN.
: * Continue as necessary with canonical ASF releases and -TRIAL CPAN
: releases until we're good.
Hmmm.... wouldn't it be better to take advantage of uplodaing -TRIAL
packages earlier in the release process?
* make RC1 of Lucy 0.3.0 (RM)
* Upload Lucy-0.3.0-TRIAL1.tar.gz to CPAN. (CPAN packager)
* If CPAN testers reveals flaws in -TRIAL pacakge, consider that when voting on RC1 (PMC)
* Repeat from top as new RCs are produced (RM)
* If vote passes re-upload final RC as Lucy-0.3.0.tar.gz (CPAN packager)
-Hoss