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

[Dionna Amalie Glaze]

On Wed, Nov 6, 2024 at 12:30 AM Stefano Garzarella <sgarzare at redhat.com> wrote:
>
> 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.
>

This seems like a nightly situation, no?
I don't know how GitHub manages different release streams. We might
want to have an svsm-nightly mirror repo that has its own releases to
not drown out the other releases on the tab.

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


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