develooper Front page | perl.perl5.porters | Postings from March 2023

Re: Deprecation doesn't mean we have two release cycles beforethings break.

Thread Previous | Thread Next
March 30, 2023 19:20
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Message ID:
On Thu, 30 Mar 2023 at 18:32, Dave Mitchell <> wrote:

> On Wed, Mar 01, 2023 at 02:11:42PM +0000, Dave Mitchell wrote:
> > On Mon, Feb 27, 2023 at 11:17:02AM +0100, demerphq wrote:
> > > But that isn't correct. Odds are *very* likely we get CPAN breakage
> from
> > > the very moment we deprecate something
> >
> > +1
> >
> > I'm particularly troubled that we have added two major deprecations
> > very late in this release cycle:
> >
> > 5.37.9:  deprecate Foo'Bar
> > 5.37.10: (not even released yet): change 'experimental' to 'deprecated':
> >             ~~, given, when, etc.
> >
> > There seems to have been a lot of CPAN test suite breakage from these.
> > Even if the fixes turn out to be trivial, and even if p5p volunteer to do
> > all the fixing, it doesn't leave a lot of time to get new releases out
> and
> > settled in.
> >
> > So I think that
> > a) such deprecations in future should only come early in the blead
> release
> >    cycle;
> > b) we should seriously consider backing out for now the two specific
> >     Foo'Bar and ~~ deprecations and re-adding them for 5.38.1.
> Well, a month has passed, and in the last week or so we've had 9 new BBCs
> related to the new smartmatch/when deprecation.

> Are we agreed or not that the Foo'Bar and smartmatch deprecations
> should be rolled back now, and re-applied in 5.39.1?

I am generally supportive of this for given/smartmatch. For apostrophe as a
package separator I am less convinced, seems like we have had less
turbulence associated with it, although the fact that we /still/ have
warnings related to it in core does not bode well for it generally. :-(

FWIW, I personally stopped trying to address these tickets. Nobody else
seemed to care about them, and many of them relate to "abandonware"[1] and
I dont see the point in writing a fix that will never get released.

I tried to get Andreas to clarify the rules about releasing fixups to
PAUSE/CPAN without having to take ownership of the distribution, but he
refused to give me a clear answer[2] so I had no choice but to assume that
you can only release something if you take ownership over it, and since I
don't wish to take ownership of a module I know nothing about I stopped
bothering with BBC tickets that are not traced back to a change I made.

I would be a lot more enthusiastic about fixing and rolling releases for
these distributions if I knew that PAUSE would accept them. It seems a
shame actually, effectively PAUSE policy about ownership discourages people
from fixing issues like this. Who wants to spend time fixing a deprecation
in a distribution you know nothing about when the author is likely absent
and PAUSE will refuse to accept the change unless you take ownership over
the module?

And if so, is anyone volunteering?

To revert the deprecations?  Seems simple enough I guess I dont mind
picking it up.

[1] Meaning the author is non-responsive to bug reports and patches.

perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About