develooper Front page | perl.perl5.porters | Postings from May 2020

Re: Perl moving above 5.x version numbers

Thread Previous | Thread Next
From:
Joseph Brenner
Date:
May 19, 2020 19:31
Subject:
Re: Perl moving above 5.x version numbers
Message ID:
CAFfgvXXJreHYaQmQz6qZv9U5xVcWaBw4Q1-jAMzUfROX_98+FQ@mail.gmail.com
(1) continue using current versioning for internal purposes

(2) for external, announcement/marketing purposes, start using the
year and month.




On 5/19/20, Dan Book <grinnz@gmail.com> wrote:
> On Tue, May 19, 2020 at 1:39 AM Darren Duncan <darren@darrenduncan.net>
> wrote:
>
>> Now that Raku has, or is in the process of, no longer using the Perl
>> version
>> namespace, has there been any serious consideration by the Perl 5 Porters
>> to
>> start exploiting version numbers above 5.x for major releases?
>>
>> I propose, if possible, that the next major production version of Perl
>> after
>> 5.32 be 34.0, and then continue on in that manner afterwards.
>>
>> As for dealing with distinguishing development versus production, the
>> smallest
>> change would be just to take the current process and shift it to the
>> left,
>> so eg
>> 33.x is dev (or as a special case could be 5.33.x as a transitional
>> exception),
>> 34.x is prod, 35.x is dev, and so on.
>>
>> Do we consider that Perl is free to independently make this move, or does
>> anyone
>> feel that Raku still has to do more than they have done first so that
>> conflicts
>> or incompatibilities can be prevented?
>>
>
> I think this is worth considering from an appearances standpoint.
>
> Let me say right out, that using 6 or 7 is out of the question. They would
> both only add to confusion and contention between communities. The Raku
> community has done a lot of work and gone through a lot of pain (and still
> are) to stop appearing to clobber Perl's namespace. A new version of Perl 6
> or 7 would just reassert these issues of identity between the two
> languages, and add confusion to the numerous resources that will be
> referencing "Perl 6" for years to come.
>
> Higher numbers are worth exploring. Consider that to the outsider, Perl 5.8
> and Perl 5.30 seem like a small difference in version. I experience this
> every time a new user says they have some ancient version of Perl and don't
> realize that 5.30 is a decade newer. This lends itself to the appearance
> that Perl is not continuously developed and does not have major releases
> every year. We know this is not true, but if we want to make it clearer to
> the public, our versioning scheme needs to better represent this reality.
>
> There is the argument that considering every major release a "major
> version" is too much, that Perl doesn't change that much. I would argue
> that we already call them major version releases, and they are already ABI
> incompatible, they already effectively are major version releases that most
> would expect, in everything but having drastically incompatible user-facing
> changes. But Perl is never going to do that, it's not what we are about. So
> there's something to be said for matching the appearance to the reality
> such as it is.
>
> Why jump to the second version number component as the major version? Sure
> it feels Java-esque. But it's already what many things treat as the major
> version, and it causes no appearance of relation to
> previously-known-as-Perl-6. It's not ideal, but it's an option. I don't
> think we should impose any deadline of doing this by 5.34 or 5.36 or
> whatever, just as examples. The logistics may seem simple but there is a
> lot of ecosystem out there to untangle.
>
> -Dan
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to doom+unsubscribe@kzsu.stanford.edu.
>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About