Re: version-0.77 and You - Part 2

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.