Perl moving above 5.x version numbers

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?

Thank you.

-- Darren Duncan
0
darren
5/19/2020 4:54:30 AM
perl.perl5.porters 48070 articles. 1 followers. Follow

8 Replies
17 Views

Similar Articles

[PageSpeed] 40

If Perl 6 is Raku now maybe we can use Perl 6 after Perl 5 later?

On 5/19/20 7:54 AM, Darren Duncan 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?
> 
> Thank you.
> 
> -- Darren Duncan

-- 
Mikhail Kozachkov
0
mchlkzch
5/19/2020 8:35:02 AM
On Mon, May 18, 2020 at 09:54:30PM -0700, Darren Duncan wrote:
> 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.

Sigh. Let's not.

-- 
Any [programming] language that doesn't occasionally surprise the
novice will pay for it by continually surprising the expert.
   -- Larry Wall
0
davem
5/19/2020 10:31:48 AM
--00000000000026acf805a5fe0733
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Presently there are books referencing Perl 6 as Raku. Perhaps it's a better
idea to bump up to 7 ?

Charlie

On Tue, May 19, 2020, 4:35 AM =D0=9C=D0=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=9A=
=D0=BE=D0=B7=D0=B0=D1=87=D0=BA=D0=BE=D0=B2 <mchlkzch@gmail.com> wrote:

> If Perl 6 is Raku now maybe we can use Perl 6 after Perl 5 later?
>
> On 5/19/20 7:54 AM, Darren Duncan 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?
> >
> > Thank you.
> >
> > -- Darren Duncan
>
> --
> Mikhail Kozachkov
>

--00000000000026acf805a5fe0733
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Presently there are books referencing Perl 6 as Raku. Per=
haps it&#39;s a better idea to bump up to 7 ?=C2=A0<div dir=3D"auto"><br></=
div><div dir=3D"auto">Charlie</div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Tue, May 19, 2020, 4:35 AM =D0=9C=D0=
=B8=D1=85=D0=B0=D0=B8=D0=BB =D0=9A=D0=BE=D0=B7=D0=B0=D1=87=D0=BA=D0=BE=D0=
=B2 &lt;<a href=3D"mailto:mchlkzch@gmail.com">mchlkzch@gmail.com</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">If Perl 6 is Raku now maybe we=
 can use Perl 6 after Perl 5 later?<br>
<br>
On 5/19/20 7:54 AM, Darren Duncan wrote:<br>
&gt; Now that Raku has, or is in the process of, no longer using the Perl <=
br>
&gt; version namespace, has there been any serious consideration by the Per=
l <br>
&gt; 5 Porters to start exploiting version numbers above 5.x for major rele=
ases?<br>
&gt; <br>
&gt; I propose, if possible, that the next major production version of Perl=
 <br>
&gt; after 5.32 be 34.0, and then continue on in that manner afterwards.<br=
>
&gt; <br>
&gt; As for dealing with distinguishing development versus production, the =
<br>
&gt; smallest change would be just to take the current process and shift it=
 <br>
&gt; to the left, so eg 33.x is dev (or as a special case could be 5.33.x a=
s <br>
&gt; a transitional exception), 34.x is prod, 35.x is dev, and so on.<br>
&gt; <br>
&gt; Do we consider that Perl is free to independently make this move, or <=
br>
&gt; does anyone feel that Raku still has to do more than they have done <b=
r>
&gt; first so that conflicts or incompatibilities can be prevented?<br>
&gt; <br>
&gt; Thank you.<br>
&gt; <br>
&gt; -- Darren Duncan<br>
<br>
-- <br>
Mikhail Kozachkov<br>
</blockquote></div>

--00000000000026acf805a5fe0733--
0
itcharlie
5/19/2020 10:48:57 AM
[top-posted]


Apologies for the brevity.



On 5/19/20 7:54 AM, Darren Duncan 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?


This is an option.


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


I'm with Dave on this. Let's not.


>
> 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 Raku have done enough to enable us to explore this.
0
xsawyerx
5/19/2020 3:45:24 PM
--000000000000bc951905a6026745
Content-Type: text/plain; charset="UTF-8"

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

--000000000000bc951905a6026745
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, May 19, 2020 at 1:39 AM Darren Du=
ncan &lt;<a href=3D"mailto:darren@darrenduncan.net">darren@darrenduncan.net=
</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">Now that Raku has, or is in the process of, no l=
onger using the Perl version <br>
namespace, has there been any serious consideration by the Perl 5 Porters t=
o <br>
start exploiting version numbers above 5.x for major releases?<br>
<br>
I propose, if possible, that the next major production version of Perl afte=
r <br>
5.32 be 34.0, and then continue on in that manner afterwards.<br>
<br>
As for dealing with distinguishing development versus production, the small=
est <br>
change would be just to take the current process and shift it to the left, =
so eg <br>
33.x is dev (or as a special case could be 5.33.x as a transitional excepti=
on), <br>
34.x is prod, 35.x is dev, and so on.<br>
<br>
Do we consider that Perl is free to independently make this move, or does a=
nyone <br>
feel that Raku still has to do more than they have done first so that confl=
icts <br>
or incompatibilities can be prevented?<br></blockquote><div><br></div><div>=
I think this is worth considering from an appearances standpoint.</div><div=
><br></div><div>Let me say right out, that using 6 or 7 is out of the quest=
ion. They would both only add to confusion and contention between communiti=
es. The Raku community has done a lot of work and gone through a lot of pai=
n (and still are) to stop appearing to clobber Perl&#39;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 b=
e referencing &quot;Perl 6&quot; for years to come.</div><div><br></div><di=
v>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&=
#39;t realize that 5.30 is a decade newer. This lends itself to the appeara=
nce that Perl is not continuously developed and does not have major release=
s every year. We know this is not true, but if we want to make it clearer t=
o the public, our versioning scheme needs to better represent this reality.=
</div><div><br></div><div>There is the argument that considering every majo=
r release a &quot;major version&quot; is too much, that Perl doesn&#39;t=C2=
=A0change that much. I would argue that we already call them major version =
releases, and they are already ABI incompatible, they already effectively a=
re 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&#39;s not what we are about. So there&#39;s something to be said =
for matching the appearance to the reality such as it is.</div><div><br></d=
iv><div>Why jump to the second version number component as the major versio=
n? Sure it feels Java-esque. But it&#39;s already what many things treat as=
 the major version, and it causes no appearance of relation to previously-k=
nown-as-Perl-6. It&#39;s not ideal, but it&#39;s an option. I don&#39;t thi=
nk 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 ecos=
ystem out there to untangle.</div><div><br></div><div>-Dan</div></div></div=
>

--000000000000bc951905a6026745--
0
grinnz
5/19/2020 4:02:07 PM
(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.
>
0
doomvox
5/19/2020 7:31:07 PM
Make sense. Why not?

And who are permitted to do such global things in Perl development 
cycle? Except for Larry of course.

On 5/19/20 1:48 PM, Charlie Gonzalez wrote:
> Presently there are books referencing Perl 6 as Raku. Perhaps it's a 
> better idea to bump up to 7 ?
> 
> Charlie
> 
> On Tue, May 19, 2020, 4:35 AM Михаил Козачков <mchlkzch@gmail.com 
> <mailto:mchlkzch@gmail.com>> wrote:
> 
>     If Perl 6 is Raku now maybe we can use Perl 6 after Perl 5 later?
> 
>     On 5/19/20 7:54 AM, Darren Duncan 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?
>      >
>      > Thank you.
>      >
>      > -- Darren Duncan
> 
>     -- 
>     Mikhail Kozachkov
> 

-- 
Mikhail Kozachkov
0
mchlkzch
5/19/2020 7:38:20 PM
Yes, what Dan said, is my motivation, its about perception that Perl is moving 
forward regularly.

Also, just shifting the numbers, whether its done for 34 or 36 or whenever we're 
ready, shows respect to Perl's long history and many updates over the years, it 
more properly represents how much has been built over the years.

Incrementing the first version per yearly release is helping Postgres' 
perception, and other projects, which have moved to doing that.

I'm not specifically proposing that this needs to be rushed for next year.

Other than the work involved to make sure the tooling and ecosystem works with 
the updated scheme, which can take as much time as it needs to, is there really 
any strong tie to calling Perl version 5 forever that people say they'd rather 
not change?

-- Darren Duncan

On 2020-05-19 9:02 a.m., Dan Book wrote:
> On Tue, May 19, 2020 at 1:39 AM Darren Duncan 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.
> 
> 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.
0
darren
5/19/2020 7:41:18 PM
Reply: