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

[Stefano Garzarella]

On Tue, Nov 05, 2024 at 08:20:03AM -0800, Dionna Amalie Glaze wrote:
>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

I proposed the SHA1 just for development release which from the 
description are simply a snapshot of the main branch, so no 
cherry-picking should be done for those releases.

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

Yep, multiple profiles can work.

Thanks,
Stefano