# from David Golden
# on Sunday 06 September 2009 07:03:

>> allow us to eliminate the whole eval($VERSION) thing
>"foolish consistency" line comes to mind...

Yes, the computer has a very little mind.

>While it relates to source rather than Meta, it intersects because
>"-TRIAL" wouldn't be in dist_version.  I think the CPAN Meta Spec
>should be explicit on how how release status is determined

Sure.  Wedging the version status into the number was always a hack.

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

>since it's just a different, abitrary variation of the "_"  hack.
>This patch is for "# ALPHA".  But on IRC others have expressed wanting
>something like unstable/testing/stable -- not just a binary state.

I only need to release a given dist with a given Module::Build once.  
It's not something that absolutely needs to stay backwards compatible.

>Others want to find ways to parse author/authority information off a
>line.

That's maybe orthogonal unless you're planning to add support for it to 
the 'use' syntax.  Even then, the declaration is probably orthogonal.

>The moment you introduce "# ALPHA" there will be some who want it to
> be:
>
>   our $VERSION = 1.23; # :status(STABLE) :auth(JDOE) :tags(web cgi
> moose)
>
>Should the first implementation win?  Should different installers do
>it different ways?

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

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

>I really don't want to do anything that leads to more installer
>framework lock in.  E.g. "I've started using M::I and I like their
>comment parsing system better so now I don't want to change from M::I
>because I don't want to have to re-write all my version line comments
>in new format.

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

>So... while in concept I like the idea of finding a way to move away
>from underscores, I'd like to reach a broader consensus before
>implementing anything.

Sure.  I would like to implement something.

At the moment, we're mainly* dealing with one consumer:  the pause 
indexer (mldistwatch).  The /TRIAL\d/ (I think I had it wrong 
as "-TRIAL") string is not supported in search.cpan.org, and probably 
elsewhere.

  http://search.cpan.org/~ewilhelm/Date-Piece-v0.0.2.TRIAL1/

(I think kobesearch just reads the index -- I don't see a way to find 
alphas in that interface.)

*mainly: the primary use of an alpha dist is to not appear in the 
02packages index, thus being skipped by an installer unless 
specifically requested.  For this usage, all you need to do is have a 
tarball name that the indexer will skip.

Of course, "not appear in" is a temporary state which gets superseded by 
a later stable release, so some info in the META.yml would be desirable 
for any sort of easily-usable historical record.

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.

--Eric
-- 
If the collapse of the Berlin Wall had taught us anything, it was that
socialism alone was not a sustainable economic model.
--Robert Young
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Reply via email to