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

[Stefano Garzarella]

On Wed, Nov 06, 2024 at 07:37:24AM -0800, Dionna Amalie Glaze wrote:
>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?

Yep, maybe not with that frequency, but yes, we can look at it from that 
perspective IIUC the proposal.

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

 From https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

     Optionally, to notify users that the release is not ready for
     production and may be unstable, select This is a pre-release.

And in the release tab there is this suggestion:

     If the tag isn’t meant for production use, add a pre-release version
     after the version name. Some good pre-release versions might be
     v0.2.0-alpha or v5.9-beta.3.

That seems to fit well with the profiles you suggested.

Thanks,
Stefano