On 7/25/09 7:43 AM, Dave Mitchell wrote:
You didn't answer this question. I am generally ignorant of the specifics
of version and version strings. I don't understand in general why bare
1.2.3 strings are deprecated (I'm sure there's a good reason for it, I'm
just not familiar with it). And in particular, I don't understand why its
particularly egregious to use one in version->new(). Understanding the
latter would give me a clearer insight as to whether to allow such a
warning in maint.
Sorry, I forget that everyone isn't as familiar with the issues as I am. ;-)
Using bare v-strings (as opposed to quoted strings) is fraught with
inconsistencies between various versions of Perl. version.pm generally
supports all major releases going back to 5.005_04, but certain facets
are rougher with the earlier Perl's. For example, prior to 5.6.0, there
were no v-strings at all. From 5.6.0 to 5.8.0, v-strings were a
tokenizer effect; once the source had been parsed, there was no evidence
that a v-string had appeared was left. Starting with 5.8.1, v-strings
became magical, in that the original source code representation was
available after tokenization.
Consequently, version.pm has to essentially guess at the author's intent
prior to 5.8.1 (and overall it does pretty well). For this reason, the
POD has always strongly recommended against using v-strings at all. On
the other hand, when I was rewriting the POD, David Golden recommended
(and I agreed) that it would be best to limit the variations that were
documented to prevent information overload. For this purpose, it seemed
best to always have a leading 'v' on dotted-decimal/dotted-integer form,
to visually distinguish from the decimal form (which just looks like a
number). This advice goes whether or not the value is quoted or not.
This simplifies the notation and makes it that much more likely that the
user will DTRT.
None of this directly impacts 5.10.1; v-strings have been safely tamed
and there is no difference between quoted and unquoted v1.2.3. However,
it would be best if the recommended notational change was backed up by
some teeth, hence the warning.
Well, nearly four weeks ago I pulled from blead into maint a "version 0.77",
which is what I understood was equivalent to what would eventually be
released onto CPAN as 0.77, less the pod which still needed writing.
Unfortunately it wasn't as simple as all that; Adam Kennedy discovered a
subtle difference between the pure Perl and xs forms of the CPAN
module. Module::Build includes an embedded copy of the pure Perl code
(so it functions the same with and without version.pm installed). And
the POD rewrite dragged on because of $WORK issues.
So what I'm hoping is that sometime soon a "0.77" appears on CPAN, which
contains no functional changes from blead, just pod additions. Someone
then pulls that into blead, then I pull it into maint, and it gets
released as 5.10.1.
I was only asking for an opinion on the warnings, not trying to pressure
you to accept a patch with which you were not comfortable.
Then, you add extra stuff to blead, release it as 0.78 etc, and at my
leisure I decide whether to incorporate it into maint.
Is it possible for you to release a 0.77 without functional changes from
blead? If not, what changes are they? And what's the connection with
Module::Build?
That is what I'll do. I have to drive to the airport presently, so this
will unfortunately wait until I get back home. But come hell or high
water this is what will happen tonight:
1) I release 0.77 to CPAN without the new strictures
2) I submit a patch to Module::Build that matches
3) I submit a patch to blead with the updated POD and tests to bring it
in line with 0.77 (someone will have to submit a patch to blead with the
matching changes from #2)
You can then pull in 2 and 3 from blead and 5.10.1 is unblocked on this
topic. #2 is for completeness purposes only; the embedded version.pm
code in M::B never fires in the core.
Later, I will submit a patch to blead and Module::Build to include the
new strictures and release 0.78 to CPAN. You don't need to worry about
that now...
Sorry if this late discussion (not completely my idea, you understand)
increased your load in any way...
John
