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

[Stefano Garzarella]

On Tue, Nov 05, 2024 at 05:12:06PM +0100, Jörg Rödel 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?

Even as a developer, sometimes I think it is useful to know how a stable 
release and development are related. For example, it might be useful for 
some sort of initial triage of a bug discovered in a development release 
to also quickly infer which stable releases might be affected.

That said, I don't have a strong opinion on this, as I think we'll 
eventually use the git repo for bisection etc. where it's easy to figure 
out the relationship between tags.

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

Yep, I agree.

Thanks,
Stefano