Re: [PATCH for-4.19] docs/checklist: Fix XEN_EXTRAVERSION inconsistency for release candidates

[Anthony PERARD <tony@xxxxxxxxxx>]

On Tue, Jul 16, 2024 at 10:22:18AM +0200, Juergen Gross wrote:
> On 16.07.24 09:46, Jan Beulich wrote:
> > On 16.07.2024 09:33, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 16/07/2024 08:24, Jan Beulich wrote:
> > > > On 16.07.2024 09:22, Julien Grall wrote:
> > > > > On 16/07/2024 07:47, Jan Beulich wrote:
> > > > > > On 15.07.2024 18:56, Julien Grall wrote:
> > > > > > > On 15/07/2024 16:50, Andrew Cooper wrote:
> > > > > > > > An earlier part of the checklist states:
> > > > > > > > 
> > > > > > > >       * change xen-unstable README. The banner (generated using 
> > > > > > > > figlet) should say:
> > > > > > > >           - "Xen 4.5" in releases and on stable branches
> > > > > > > >           - "Xen 4.5-unstable" on unstable
> > > > > > > >           - "Xen 4.5-rc" for release candidate
> > > > > > > > 
> > > > > > > > Update the notes about XEN_EXTRAVERSION to match.
> > > > 
> > > > When this is the purpose of the patch, ...
> > > > 
> > > > > > > We have been tagging the tree with 4.5.0-rcX. So I think it would 
> > > > > > > be
> > > > > > > better to update the wording so we use a consistent naming.
> > > > > > 
> > > > > > I find:
> > > > > > 
> > > > > > 4.18-rc
> > > > > > 4.17-rc
> > > > > > 4.16-rc
> > > > > > 4.15-rc
> > > > > 
> > > > > Hmmm... I don't think we are looking at the same thing. I was
> > > > > specifically looking at the tag and *not* XEN_EXTRAVERSION.
> > > > 
> > > > ... why would we be looking at tags?
> > > 
> > > As I wrote, consistency across the naming scheme we use.
> > > 
> > > > The tags (necessarily) have RC numbers,
> > > 
> > > Right but they also *have* the .0.
> > > 
> > > > so are going to be different from XEN_EXTRAVERSION in any event.
> > > 
> > > Sure they are not going to be 100% the same. However, they could have
> > > some similarity.
> > > 
> > > As I pointed out multiple times now, to me it is odd we are tagging the
> > > tree with 4.19.0-rcX, but we use 4.19-rc.
> > > 
> > > Furthermore, if you look at the history of the document. It is quite
> > > clear that the goal was consistency (the commit mentioned by Andrew
> > > happened after). Yes it wasn't respected but I can't tell exactly why.
> > > 
> > > So as we try to correct the documentation, I think we should also look
> > > at consistency. If you *really* want to drop the .0, then I think it
> > > should happen for the tag as well (again for consistency).
> > 
> > I don't see why (but I also wouldn't mind the dropping from the tag).
> > They are going to be different. Whether they're different in one or two
> > aspects is secondary to me. I rather view the consistency goal to be
> > with what we've been doing in the last so many releases.
> 
> Another aspect to look at would be version sorting. This will be interesting
> when e.g. having a Xen rpm package installed and upgrading it with a later
> version. I don't think we want to regard replacing an -rc version with the
> .0 version to be a downgrade, so the the version numbers should be sorted by
> "sort -V" in the correct order.

Packages version from distribution is not something we have to deal with
upstream. It's for the one writing the package version to make sure
that -rc are older than actual release.

While trying to to find if SPEC files where dealing with "-rc" suffix,
I found a doc for fedora telling how to deal with RCs:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
They say to replace the dash with a tilde, so "-rc" become "~rc", and
package manager know what to do with it.

Some other distribution know how to deal with "rc" suffix, but the dash
"-" isn't actually allowed in the version string:
https://man.archlinux.org/man/vercmp.8

So unless we forgo "-rc" in tags, there's no way we can take into
account how distributions package manager sorts version numbers. Also,
there's no need to, it is the job of the packager to deal with version
number, we just need to make is simple enough and consistent.

Cheers,

-- 
Anthony PERARD