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 <<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>> 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 <<a href=3D"mailto:[email protected]" target=3D"_blank">fawa= [email protected]</a>> writes:<br>> That said, I would really appreciate i= t if in the future people would<br> > talk a bit more with their upstreams when incrementing their perl<br> > 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't know where to do it.=C2= =A0 Maybe<br> perl5-porters, which I haven'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'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'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'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'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'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->@* syntax instead of @{ $foo },= <br> so eventually it would be nice to require Perl 5.024 or later, although I<b= r> know that's much too aggressive at the moment.<br></blockquote><div><br= ></div><div>There's an interesting conundrum there. If the toolchain do= esn't depend on any new functionality you'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--