[svsm-devel] [RFC] COCONUT-SVSM Release Process

[Jörg Rödel]

Hi Stefano,

On Tue, Nov 05, 2024 at 12:23:42PM +0100, Stefano Garzarella wrote:
> My concern is having two types of release in the same month, e.g.
> R2025.03 and D2025.03.
> 
> How do we know which one happened sooner or later?

Stable releases are branched off at least 4 weeks before they are
tagged, so it is safe to assume that, given a development and stable
release in the same month, the development release will be based on a
more recent code base.

The stable and development releases also target different groups of
users, so I wonder why it is important to know which release happened
first?

> Or do we never expect to have a stable release and a development
> release in the same month?

Stable an development releases in the same month are allowed, I do not
want to forbid that.

> I'm not sure if using YYYY.NN is better, where NN is a counter shared
> among all release types (D or R).

I'd like to avoid sharing counters between development and stable
releases. This would indicate a relationship between these release types
that does not exist. Each release type targets a different
audience/use-case.

> Another option is to increase the counter only for a stable release
> (or use the month in this case), and for development releases, add a
> few digits of the SHA-1 of the commit, something like this:
> 
> R2025.03
> D2025.03-g9ec10216
> D2025.03-g5f4987a1
> D2025.03-gbb6e9222
> R2025.04

This might turn version comparisions for package managers into a real
nightmare. If we include the sha1 of the top-commit, we still need a
growing number to ensure version string ordering.

But I see the problem you are trying to solve, we need a way to cope
with multiple development releases per month. This can be solved with
adding another counter to the YYYY.MM part.

Regards,

-- 
Jörg Rödel
jroedel at suse.de

SUSE Software Solutions Germany GmbH
Frankenstraße 146
90461 Nürnberg
Germany
https://www.suse.com/

Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)