[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, Jul 16, 2024 at 03:55:58PM +0200, Anthony PERARD wrote:
> 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.

XEN_EXTRAVERSION isn't only about version for packaging (where indeed
some changes for -rc will likely be needed anyway, as different packages
have different ways of dealing with it). It's also about version
reported by Xen in various places like `xl info xen_version`. IMO it
makes sense to have consistent format there (always 3 parts separated by
a dot). It makes live easier for any tooling making use of this value.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.