On Sat, Jul 25, 2009 at 06:58:42AM -0700, John Peacock wrote:
> On 7/25/09 1:52 AM, Dave Mitchell wrote:
>> In general we try strongly to avoid making code that works suddenly start
>> emitting warnings under later releases of the same maintenance branch.
>>
>> However, I don't understand what the particular issue of using v-strings
>> to initialize version objects is?
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.
>> But whatever, I really don't want a new warning for 5.10.1 at this very
>> late stage in the game.
>>
>>
> None of the third-party modules in the core changed their warning
> profile between 5.10.0 and 5.10.1-to-be?
That's not what I said. I said "at this late stage in the game". i.e.
the one thing I'm not going to go is to add a new warning to a core
pragma *one day* before RC1 is released.
> I fully support not making the
> bare v-string code warn except in blead and hence for 5.12.0. I'd
> really rather keep the warning in version.pm just the same.
>
> However, it is your call completely - I just added the warning to
> bleadperl (but didn't update any tests). Outside of the version.pm
> tests, there was only a single warning from t/pod/diag.t and a couple of
> warnings seen from the Module::Build tests (which would also have to be
> adjusted since it depends on version.pm and expectations have changed).
>
> I'm traveling today, so I can do whatever needs doing when I get home
> tonight. I'd prefer to apply this change:
>
> diff --git a/util.c b/util.c
> index 0d524e9..f088e73 100644
> --- a/util.c
> +++ b/util.c
> @@ -4260,8 +4260,12 @@ Perl_scan_version(pTHX_ const char *s, SV *rv,
> bool qv)
> if ( alpha && saw_period && width == 0 )
> Perl_croak(aTHX_ "Invalid version format (misplaced _ in number)");
>
> - if ( saw_period > 1 )
> + if ( saw_period > 1 && qv == 0) {
> qv = 1; /* force quoted version processing */
> + if(ckWARN(WARN_SYNTAX))
> + Perl_warner(aTHX_ packWARN(WARN_SYNTAX),
> + "v-string without leading 'v' deprecated for version objects");
> + }
>
> last = pos;
> pos = s;
>
> plus the test fixups to blead and then have that go into maint. If you
> aren't comfortable with that, I'll just update just the POD and you can
> pull that. I'm inclined to make an immediate CPAN release after 0.77
> (to match what is in 5.10.1) to include that warning, however, because I
> agree with David Golden that the clarity it provides is valuable...
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.
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.
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?
--
Technology is dominated by two types of people: those who understand what
they do not manage, and those who manage what they do not understand.
