diff mbox series

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

Message ID 20240715155051.3375999-1-andrew.cooper3@citrix.com (mailing list archive)
State New
Headers show
Series [for-4.19] docs/checklist: Fix XEN_EXTRAVERSION inconsistency for release candidates | expand

Commit Message

Andrew Cooper July 15, 2024, 3:50 p.m. UTC
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.

Fixes: 15241c92677a ("process/release-technician-checklist: Explain how the banner in README is generated")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
---
 docs/process/release-technician-checklist.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: 1ddc8c1bad93aa6cbfe616dd72333460c47f96c9

Comments

Julien Grall July 15, 2024, 4:56 p.m. UTC | #1
Hi,

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.

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.

Cheers,
Jan Beulich July 16, 2024, 6:47 a.m. UTC | #2
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.
> 
> 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

Do I need to go any further? Your 4.5 example also doesn't fully fit because
at that time we were, in addition, still appending RC numbers (up to and
including 4.9 as it looks). In 4.10 it then (intermediately) indeed was
4.10.0-rc. In 4.11 it became 4.11-rc.

That said I wouldn't strictly mind the .0 infix. It's just that imo shorter
is better, and the .0 doesn't really convey any useful information anymore
now that we don't do / tag stable release RCs any longer.

Jan
Jan Beulich July 16, 2024, 6:51 a.m. UTC | #3
On 15.07.2024 17: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.
> 
> Fixes: 15241c92677a ("process/release-technician-checklist: Explain how the banner in README is generated")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
Julien Grall July 16, 2024, 7:22 a.m. UTC | #4
Hi Jan,

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.
>>
>> 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.

42sh> git tag | grep rc

3.0.2-rc
3.2.0-rc1
3.2.0-rc2
3.2.0-rc3
3.2.0-rc4
3.2.0-rc5
3.2.0-rc6
3.3.0-rc1
3.3.0-rc2
[...]
4.14.0-rc1
4.14.0-rc2
4.14.0-rc3
4.14.0-rc4
4.14.0-rc5
4.15.0-rc1
4.15.0-rc2
4.15.0-rc3
4.15.0-rc4
4.15.0-rc5
4.16.0-rc1
4.16.0-rc2
4.16.0-rc3
4.16.0-rc4
4.17.0-rc1
4.17.0-rc2
4.17.0-rc3
4.17.0-rc4
4.18.0-rc1
4.18.0-rc2
4.18.0-rc3

> 
> Do I need to go any further? Your 4.5 example also doesn't fully fit because
> at that time we were, in addition, still appending RC numbers (up to and
> including 4.9 as it looks). In 4.10 it then (intermediately) indeed was
> 4.10.0-rc. In 4.11 it became 4.11-rc.

See above.

> 
> That said I wouldn't strictly mind the .0 infix. It's just that imo shorter
> is better, and the .0 doesn't really convey any useful information anymore
> now that we don't do / tag stable release RCs any longer.

So you are arguing for shortening the name. I am arguing for consistency 
across the naming. We can do both, but we would need to tag the tree 
with "4.X-rcY".

Cheers,
Jan Beulich July 16, 2024, 7:24 a.m. UTC | #5
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? The tags (necessarily) have RC numbers,
so are going to be different from XEN_EXTRAVERSION in any event.

Jan
Julien Grall July 16, 2024, 7:33 a.m. UTC | #6
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).

Cheers,
Jan Beulich July 16, 2024, 7:46 a.m. UTC | #7
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.

Jan
Jürgen Groß July 16, 2024, 8:22 a.m. UTC | #8
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.

This would mean that we'd need to use:

4.19-rc
4.19.0
4.19.1


Juergen
Anthony PERARD July 16, 2024, 1:55 p.m. UTC | #9
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,
Marek Marczykowski-Górecki July 16, 2024, 8:10 p.m. UTC | #10
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.
diff mbox series

Patch

diff --git a/docs/process/release-technician-checklist.txt b/docs/process/release-technician-checklist.txt
index 4b061bf5f20b..e6db02b87585 100644
--- a/docs/process/release-technician-checklist.txt
+++ b/docs/process/release-technician-checklist.txt
@@ -67,7 +67,7 @@  t=RELEASE-$r
 # if main version number has changed (eg 4.7 -> 4.8) rerun ./autogen.sh
 * rerun ./autogen.sh to update version number in configure
 #    - XEN_EXTRAVERSION should be as follows
-#      `.0-rc$(XEN_VENDORVERSION)'       during freeze, first rc onwards (including staging, before branching)
+#      `-rc$(XEN_VENDORVERSION)'         during freeze, first rc onwards (including staging, before branching)
 #      `-unstable$(XEN_VENDORVERSION)'   unstable aka unfrozen staging (or unstable branch, after branching)
 #      `.0$(XEN_VENDORVERSION)'          actual release of Xen X.Y.0 (aka first actual release of Xen X.Y)
 #      `.Z$(XEN_VENDORVERSION)'          actual release of Xen X.Y.Z (stable point realase)