From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Anthony PERARD <tony@aperard.fr>
Cc: Juergen Gross <jgross@suse.com>, Jan Beulich <jbeulich@suse.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Oleksii Kurochko <oleksii.kurochko@gmail.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH for-4.19] docs/checklist: Fix XEN_EXTRAVERSION inconsistency for release candidates
Date: Tue, 16 Jul 2024 22:10:34 +0200 [thread overview]
Message-ID: <ZpbTuxLaaXDHnRYb@mail-itl> (raw)
In-Reply-To: <ZpZ77uJ/wuhoxR2p@l14>
[-- Attachment #1: Type: text/plain, Size: 4768 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-07-16 20:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 15:50 [PATCH for-4.19] docs/checklist: Fix XEN_EXTRAVERSION inconsistency for release candidates Andrew Cooper
2024-07-15 16:56 ` Julien Grall
2024-07-16 6:47 ` Jan Beulich
2024-07-16 7:22 ` Julien Grall
2024-07-16 7:24 ` Jan Beulich
2024-07-16 7:33 ` Julien Grall
2024-07-16 7:46 ` Jan Beulich
2024-07-16 8:22 ` Juergen Gross
2024-07-16 13:55 ` Anthony PERARD
2024-07-16 20:10 ` Marek Marczykowski-Górecki [this message]
2024-07-16 6:51 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZpbTuxLaaXDHnRYb@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=oleksii.kurochko@gmail.com \
--cc=sstabellini@kernel.org \
--cc=tony@aperard.fr \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.