Re: Better perldelta management

On Fri, 17 Jul 2026 09:44:13 +0200
"Philippe Bruhat (BooK)" <[email protected]> wrote:

> > I'm currently in the middle of merging the billion or so (or at
> > least it feels like) pending PRs now that we have 5.44.0 out the
> > door. One thing that is striking me is that a lot of them are
> > causing silly conflicts simply due to concurrent edits in
> > perldelta.pod. If not for that one conflicting file, I think
> > there'd be under half the current number of conflicts.  
> 
> I will note that this is not the usual workflow for a blead final,
> after a feature freeze. It is, however typically what's happening in
> a regular bleadpoint release. Except you've hit all the conflicts at
> once, when in general every individual who merges a PR has to deal
> with the conflicts, one at a time. Your current pain level is kind of
> an exception.

I disagree. The *extent* of the conflicts is exceptional at this time,
but it's not at all uncommon to have conflicts in perldelta whenever
there are multiple PRs in flight - and that's quite often the case.

> And so we end up adding the deltas *after* the merge, having the
> release manager call out for deltas a few days before the release,
> instead of keeping the delta nicely tugged in the branch, as work
> continues on the feature.
> 
> I wonder if this new approach might lead to longer individual deltas.

Yeah indeed. My intended workflow if we had this new mechanism would be
to keep my own perldelta fragment up to date with every individual
commit along the feature branch.

> >  3. Add a step to the RMG for a BLEAD-POINT release which runs
> > BooK's tool with the generic template and all the files this
> > directory, so it spits out the merged file. Some manual shuffling
> > of order might be useful, to sort multiple additions in the same
> > section into a good order for relevance, but overall this shouldn't
> > need much work.  
> 
> I think step 3 would be a little different. The sections can be
> managed by keeping the =head1/=head2 in the tiny file, and the order
> of the different elements in the same section can be inferred from
> the moment that file was mergedi (or last edited).

Annoyingly, git doesn't preserve the moddate on files as such. All of
your local fragment files will just appear to have the moddate of
whenever git last touched it. If you just did `git pull` and it added
lots of files since your last update, you won't know which is which.

> The main benefit in my mind is that the delta for a given change can
> be kept alongside the changes themselves, in the branch, until it's
> merged. And that removes conflict opportunities (at least regarding
> perldelta).

Mmyes, I agree (see above).

> The script will need to be adapted, since it's going to take the
> content from the pod/perldelta.pod.d/ directory, and optionally from
> the developement perldeltas when building the blead final release.
> 
> This sounds very doable.

I'm having a hack at it now.

-- 
Paul "LeoNerd" Evans

[email protected]
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS