Re: alpha dists without the underscores

On Sun, Sep 6, 2009 at 1:39 PM, Eric Wilhelm<[email protected]> wrote:
>>> For reason #2, I'm reluctant to do it with e.g. a command-line
>>> option or Build.PL parameter.  Some sort of artifact in the deployed
>>> .pm is very useful for debugging an installed module.
>>
>>I have mixed feeling about this.  Until *Perl* has specific semantics
>>around this, I'm reluctant to add semantics in the form of comments,
>
> I think comments are going to be the least invasive/verbose mechanism.
> You want to use the pod?
>
> I would be very sad to see a runtime module requirement just to declare
> some rarely-used meta info.  Ditto for requiring a new Perl.

POD?  Hell, no.

But, for the sake of argument, let's say some bold, foolish programmer
implements an extended 'package' keyword for Perl, like so [1]:

    package Foo 1.23;

And, following popular demand, at least based on #corehackers and
#toolchain, he implements a way of marking module release status, like
so:

    package Foo 1.23 stable;

And lets assume that "stable" "testing" and "unstable" were the
allowed status flags to an enhanced package line.  If such a patch
were added to core, clearly, M::B and EU::MM would need to be patched
accordingly.

As you say, that's fine for future Perls, but what about older ones?
I would argue that using comments as a backward compatible hack is OK,
but that stable/testing/unstable should be used instead of ALPHA.

That's a contrived case to be sure, but my point is that I'd like to
figure this out once and not have one semantic for M::B, one for
blead, another one for M::I, no semantic at all in EU::MM and so on.

It's all the same problem, so I'd like Oslo-style consensus, so if we
have to use ugly hacks, the whole toolchain is consistent with it.
E.g. The Olso consensus around listing "perl" in "requires" -- even
Schwern came around and joined the consensus to keep it [thank you,
Schwern!].

Give me consensus and I'll be the front ranks of implementers, but if
the idea is Module::Build blazing a trail, I'm violently opposed.

> As I said, I only need to do it one way once with a given M::B.  If a
> better mechanism is developed, I'll use that the next time.  (I know
> we're good at thinking of edge cases around here so I'll
> preemptively 'meh' all of those now.)

Rebuttals to your "meh": YAML for Meta, version.pm, PERL5_CPANPLUS_IS_RUNNING

There are a lot of dubious decisions that seemed like good ideas at
the time that we maintainers are living with.  So "meh" to your "meh".
 :-)

>>Should we bikeshed the issue to death?
>
> I don't mind if other people's problems also get solved.  I do mind if
> my problem gets snowed under an architectural astronomy project. ;-)

Agreed.  Bound the problem around how flag, capture and communicate
distribution status and let the rest of the meta issues go.

> Iff you extend it beyond the "# ALPHA" without developing something
> formal and reproducible, this is what you'll get.

(formal and reproducible)++

> If we're adding something to META.yml and can change mldistwatch to see
> that, we don't even need a specially-formatted tarball name.

Exactly.

My suggestion is:

* Define a 'release_status' field in the new CPAN Meta Spec that
clarifies the semantics of what a release status is, and whether there
are synonyms for various release levels. (E.g. alpha = unstable, beta
= testing, is there a 'release candidate' status, and so on)

* Have PAUSE start using the new field if it exists

Then, and only then, do we figure out if it should be a comment, or
just be set in Build.PL or whatever because we'll have thought through
the issues with other toolchain developers and can probably quickly
agree on a common approach.

-- David

    [1] http://github.com/dagolden/perl/tree/package-name-version