Re: podlators 5.00 released

[email protected] (Leon Timmermans) Sat, 31 Dec 2022 02:09:46 +0100
Newsgroups perl.pod-people
Message-ID <CAHhgV8j-DM_S=hNN-QWPy+kR2c12ZLE1_U5RbKwRJQgaEZzB9g@mail.gmail.com>
--00000000000073ea2c05f1156079
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 26, 2022 at 5:38 PM Russ Allbery <[email protected]> wrote:

> Leon Timmermans <[email protected]> writes:
> > That said, I would really appreciate it if in the future people would
> > talk a bit more with their upstreams when incrementing their perl
> > dependency; this could easily have been not so easy to work around.
>
> Is there a forum in which this sort of conversation takes place?  I would
> be happy to have this discussion; I just don't know where to do it.  Maybe
> perl5-porters, which I haven't been subscribed to for some years (although
> I send release notifications here) because it used to be super-high
> volume, but maybe it's not any more?
>

I guess p5p would have been the most obvious place to have this discussion
in this particular case. Toolchain doesn't really do email for some reason.


> Anyway, the reason why I thought this was safe is because Pod::Man is part
> of Perl core, so it's always available.  I assume the problem is that
> Module::Build is requesting a later version than what comes with Perl in
> 5.8 (for Unicode support), and CPAN doesn't have the same support that
> PyPI has for providing multiple versions and being able to fall back on an
> older version if the newer version doesn't meet available constraints
> (such as not supporting the current version of Perl)?
>

Yeah, I can see where that assumption comes from.


> In the future, I would like to be able to use the package NAMESPACE VERSION
> syntax instead of $VERSION and the $foo->@* syntax instead of @{ $foo },
> so eventually it would be nice to require Perl 5.024 or later, although I
> know that's much too aggressive at the moment.
>

There's an interesting conundrum there. If the toolchain doesn't depend on
any new functionality you're not constrained there, but that also means
that any such new functionality goes largely unused.

Leon

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

<div dir=3D"ltr">On Mon, Dec 26, 2022 at 5:38 PM Russ Allbery &lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:<div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Leo=
n Timmermans &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">fawa=
[email protected]</a>&gt; writes:<br>&gt; That said, I would really appreciate i=
t if in the future people would<br>
&gt; talk a bit more with their upstreams when incrementing their perl<br>
&gt; dependency; this could easily have been not so easy to work around.<br=
>
<br>
Is there a forum in which this sort of conversation takes place?=C2=A0 I wo=
uld<br>
be happy to have this discussion; I just don&#39;t know where to do it.=C2=
=A0 Maybe<br>
perl5-porters, which I haven&#39;t been subscribed to for some years (altho=
ugh<br>
I send release notifications here) because it used to be super-high<br>
volume, but maybe it&#39;s not any more?<br></blockquote><div><br></div><di=
v>I guess p5p would have been the most obvious place to have this discussio=
n in this particular case. Toolchain doesn&#39;t really do email for some r=
eason.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">
Anyway, the reason why I thought this was safe is because Pod::Man is part<=
br>
of Perl core, so it&#39;s always available.=C2=A0 I assume the problem is t=
hat<br>
Module::Build is requesting a later version than what comes with Perl in<br=
>
5.8 (for Unicode support), and CPAN doesn&#39;t have the same support that<=
br>
PyPI has for providing multiple versions and being able to fall back on an<=
br>
older version if the newer version doesn&#39;t meet available constraints<b=
r>
(such as not supporting the current version of Perl)?<br></blockquote><div>=
<br></div><div>Yeah, I can see where that assumption comes from.<br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In the fu=
ture, I would like to be able to use the package NAMESPACE VERSION<br>
syntax instead of $VERSION and the $foo-&gt;@* syntax instead of @{ $foo },=
<br>
so eventually it would be nice to require Perl 5.024 or later, although I<b=
r>
know that&#39;s much too aggressive at the moment.<br></blockquote><div><br=
></div><div>There&#39;s an interesting conundrum there. If the toolchain do=
esn&#39;t depend on any new functionality you&#39;re not constrained there,=
 but that also means that any such new functionality goes largely unused.</=
div><div><br></div><div>Leon<br></div></div></div>

--00000000000073ea2c05f1156079--