Re: commits for possible 5.9.1

[Oliver Kiddle <opk@xxxxxxx>]

Bart Schaefer wrote:
>
> If the point of this discussion is to create a relatively stable
> 5.9.1, then namerefs are not a good candidate.

In suggesting a 5.9.1 to dana, I was most definitely not considering
namerefs or anything that warranted an entry in the NEWS file to be in
scope. Just minor bug fixes, portability/build fixes and pcre2 because
that's already getting widely backported by distros to ease their
dependencies. 51670 would be another example. We could opt to pull in
rather more, including most completion updates (minus the Base and Zsh
subdirectories) - we were fairly generous on those in the 4.0 and 4.2
branches. But the smaller we keep it, the less effort is involved.

> > [...] that would mean we can go straight to a
> > full release, which saves a lot of legwork.
>
> In that case I (or someone) would need to finish applying the five (?)
> patches Philippe has already produced, and we should just go right
> ahead to 5.10 and not call it 5.9.1.

Are those five patches what is required to get namerefs into a state
where you and Philippe are happy with their state? If more time is
needed to get them right, then better to take your time and we do 5.9.1
as a stopgap.

Aside from namerefs, we could use a round of identifying missed patches
and some late cleanups.

I would also suggest we consider 6.0 for the next full release, my
rationale being:-

  * The number of fairly major changes: namerefs, namespaces and nofork
  alone is substantial enough.
  * The removal or restricted can be seen as breaking backward
  compatibility for semantic versioning purists. And there are
  other examples.
  * The major jump will give more forewarning to those users who'll
  complain about the terminal queries.
  * 10 putting us in double digits
  * There's been a big gap since the 5.10 pre-releases so it'd draw
  a clear distinction between those and the next set of pre-releases.
  * There's a 3-part version number, let's use it. I'd like to wish that
  we avoid four year gaps happening again - achieving that would also
  limit future opportunities to up the major version.
  * And with that gap in mind, the project really needs the show of
  vitality that a major release would provide.

Oliver