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

[Dionna Amalie Glaze]

On Tue, Nov 5, 2024 at 8:12 AM Jörg Rödel <jroedel at suse.de> wrote:
>
> 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.
>

A scheme we use has been YYYY-MM[-DD][-profile][-rcX]
The profile marker is to allow for different build profiles from the same trunk.
I don't think that releases from a SHA1 hash make sense, since I would
always presume that cutting a release tag means creating a branch upon
which to cherry-pick fixes. Cherry-picking on top of the named SHA1
hash changes the head hash and kind of ruins it.
If you want D to mean unstable features but are not broken outright,
I'd say to call it the unstable profile. That way you make sure to
track experimental/unstable additions behind features that you can
later promote to stable.

I wouldn't worry too much about creating multiple canonical profiles
at this point though.

> 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)
> --
> Svsm-devel mailing list
> Svsm-devel at coconut-svsm.dev
> https://mail.8bytes.org/cgi-bin/mailman/listinfo/svsm-devel



-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)