[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |