develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Pre-RFC: perldelta naming

Thread Previous | Thread Next
Nicholas Clark
January 7, 2022 08:59
Re: Pre-RFC: perldelta naming
Message ID:
This suggestion doesn't need to be an RFC (so it doesn't need to be a
pre-RFC). It's a valid suggestion, but we're rather over-using the "I'm
going to call it a pre-RFC" thing now. And pre-RFC's were supposed *only*
to be the pitch for "do I write a proper RFC". All this seems to have got
a bit confused.

On Fri, Jan 07, 2022 at 12:50:07AM -0800, Darren Duncan wrote:
> On 2022-01-07 12:26 a.m., Alexander Hartmaier wrote:
> > Dear Porter,
> > currently the perldelta pod is renamed on every version to
> > perl$version_without_dotsdelta on every release.
> > I'd like to ask if we can't name the file that way when it is created so
> > that it doesn't have to get renamed later?
> > Keeping perldelta as an index for all available version specific files,
> > maybe highlighting the major changes, new features, important bug- and
> > security fixes, if something relies on its existence.
> > 
> > Thanks, Alex
> I like this idea.  Create every Perl Delta file from now on using its final
> name inclusive of version number, and have the generic "perldelta" be a
> concise index of sorts that mainly points to the numbered file for the
> latest version.  This index can also have a brief explanation of how to read
> the other files and which ones are most relevant. -- Darren Duncan

I know that we changed it, but I couldn't remember why. I *can* remember
that there were pain points both ways. I went for a quick look through git
history (available to all of us). The change was this:

Author: Florian Ragwitz <>
Date:   Sun Aug 22 10:43:37 2010 +0200

    Move the latest perldelta to pod/perldelta.pod

    This way patches including perldelta entries will apply properly, no matter when
    they are applied. If there's conflicts, they'll at least be in the right file.

Since that change there have been a whole bunch of improvements in our
"tooling" for making releases, some of which assume an unchanging filename
as their target. So if we think that the trade off is worth it, changing
back to the old plan is *not* as simple as reverting that commit.

I'd be interested as to what release managers and folks who regularly apply
patches think. (Or if anyone wants to try implementing this change and then
roll a release tarball locally to see how it works)

Nicholas Clark

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