handling Module::CoreList in maint branches

(this is similar to my other thread about handling perlhist/delta in
maint branches.)

The Release Manager's Guide (RMG) suggests that every update in a maint
branch to CoreList.pm should actually be done in blead and then
cherry-picked into the maint branch. That way, each maint branch has a
completely up-to-date record of all releases (so for example 5.14.x knows
about 5.16.x etc).

In practice this hasn't been happening. For example, the maint-5.14 branch
still has the 2.49 version of Module::CoreList that was distributed with
5.14.0, except that the version has been bumped to 2.49_07 and information
for the new 5.14.x releases has been added. It knows nothing about the
5.15, 5.16, 5.17 releases.

I think its happened this way (i.e. people haven't followed the "official"
instructions) because the instructions are impossible to actually follow
in practice.

Module::CoreList is complicated by the fact that

1) it's a dual-lived module, so version numbers and content need keeping
synced with CPAN;
2) it's a highly self-referential module; for example as well as knowing
about the current version number of all modules in the new perl release,
it needs to say what version of Module::CoreList was released with this
perl, and it wants to know the date that the new perl was released
3) t/porting/cmp_version.t complains bitterly each time an addition is
made to CoreList.pm without the version being bumped - so you have to
keep bumping the version for every RC release and for FINAL.

So I'm not sure what to do about this. At the very least, the RMG
instructions need updating to match actual current practise, but ideally
current practise could be improved too.

Here's a suggestion for a new modus operandi:

* The version in blead is kept always up-to-date (knows about *all*
* releases) and is usually in sync with cpan;
* At the start of the process of making a new maint release, the current
blead version of CoreList.pm is copied into maint;
* from then onwards, the various RC releases just do a _00N bump of the
local version with info on the new RC release.

For the final release for that maint branch (following the RCs), I can see
two approaches: just release it as _00N+1, then at your leisure merge the
new updates back into blead. The downsides of this approach are that we
release _00N devel versions of CoreList.pm with final releases of maint,
and that the same 2.MMM_NNN version may appear in two different maint
releases if they happen around the same (e.g. 5.14.4 and 5.16.3), even
though they don't have the same content.

The second approach I can see would be: between the final RC and FINAL,
put any local (maint) changes back into blead, bump the blead version
number to a full new step (not an _00N), then pull that back into maint.
The downside of that approach is that the blead CoreList.pm may have
received updates in between the first maint -RC1 and the maint FINAL, so
the differences between the last maint RC and maint final may be bigger
than they strictly need to be (and you always want to keep the changes
between last RC and final as small as possible).

But I don't really know what's best.

Also, currently Chris seems to be handling pulling updated from maint
branches back into blead. Chris, are you happy to continue doing this?
If so, should it be enshrined in the RMG? But if we go for the second
approach above, then it would really need doing by the pumpkin, at the
point when they are preparing the final maint release.

-- 
The warp engines start playing up a bit, but seem to sort themselves out
after a while without any intervention from boy genius Wesley Crusher.
    -- Things That Never Happen in "Star Trek" #17

• handling Module::CoreList in maint branches by Dave Mitchell
• Re: handling Module::CoreList in maint branches by Dave Mitchell
• Re: handling Module::CoreList in maint branches by Chris 'BinGOs' Williams