Initial proposal for short-term release process #360

jacderida · 2024-07-08T23:10:17Z

No description provided.

0001-short-term-release-process/0001-release-process-short-term.md

Az80386 · 2024-07-11T22:24:30Z

Just throwing this general question out there, other than the label release candidate vs alpha coming from main branch carved as branch: YYYY-MM-DD-rc.1 or YYYY-MM-DD-alpha.1 , its basically a build that is coming from non-stable branch going out to be tested, and later those changes get accepted later into stable and/or main, and if its the release candidate when adequate burn in happens with community (assuming this is true), (say one week) is then accepted into stable, and the stable release process kicks in.

Does the team want this functionality and overhead here at this time? Are we trying to have some of the community members trying to join alpha builds, as oppose to release candidates builds, and pick between one or both based on their limited resources and time in a very aggressive time line as is?
At any point in time a release candidate or alpha version if given to the community doesn't necessarily have to be accepted and changes don't have to go back to stable or main respectively, and the team controls that decision.

0001-short-term-release-process/0001-release-process-short-term.md

joshuef · 2024-07-12T00:30:17Z

Does the team want this functionality and overhead here at this time?

I think we don't necessarily have to leverage it, but if it's clear from this proposal we'll at least be on the same page. I agree with chris' proposal here as I understand it, so we have the naming to reflect stability / testing status.

As when those might be put out to the community would depend on what we need to test/how eg.

jacderida · 2024-07-12T12:09:25Z

Just throwing this general question out there, other than the label release candidate vs alpha coming from main branch carved as branch: YYYY-MM-DD-rc.1 or YYYY-MM-DD-alpha.1 , its basically a build that is coming from non-stable branch going out to be tested, and later those changes get accepted later into stable and/or main, and if its the release candidate when adequate burn in happens with community (assuming this is true), (say one week) is then accepted into stable, and the stable release process kicks in.
* Does the team want this functionality and overhead here at this time?  Are we trying to have some of the community members trying to join alpha builds, as oppose to release candidates builds, and pick between one or both based on their limited resources and time in a very aggressive time line as is?

* At any point in time a `release candidate` or `alpha version` if given to the community doesn't necessarily have to be accepted and changes don't have to go back to `stable` or `main` respectively, and the team controls that decision.

I actually do agree with you that it could potentially be a bit confusing to have the alpha releases in three week cycles, but I think given what Josh has said, I'm going to just leave it in the proposal. I think it's unlikely we will actually make use of it, but it's there just in case. Thanks for the input on this one.

* Clarify the problem with merging in the Gitflow model * Clarify use of "comp" to "competition" * Remove uncertainty around the auditor and faucet binaries being part of the package * Remove uncertainty around `NETWORK_VERSION` * Refine the hotfix process to include `rc.1` pre-release specifier * Clarify that the Github Release creates a tag * Provide more clarity on the phases within the schedule * Clarify that the RC will be open to community users for testing * Shu has clarified the use of `X` and `Y` within the bundled version number

There was a concern raised that specifying a development phase of 2 weeks implied that development would stop after those two weeks. To avoid this, I am now emphasizing that development is an ongoing process. To support this: * Removed references to development phases in the `Beta Release Cycles and Schedule` section. There are now only dates for when a QA/RC phase would start and when a deployment would occur. * The `Release Cycle Overview` section also removes the length of the development phase, trying to emphasize that development is continuous.

We held a meeting to discuss outstanding issues around the process. It was agreed we would go with a release cycle supporting two releases per month, roughly separated by two week intervals. Two releases per month doesn't necessarily map on to a release every two weeks. A few other miscellaneous issues were addressed. This commit modifies the process in accordance. Details: * Remove release schedule section: with a two-week-per-month release cycle we don't need the schedule section laying out the release dates. The release cycles will no longer map to 'waves' in the beta programme. * In the cycle overview section, some additional steps provide more clarity, and the duration of the RC phase is updated to two weeks. * Update the artifacts section to describe the versioning solution we agreed to. * Update the RC process to describe the two-week cycle. * Update the RC process to describe cherry picking fixes into `main`.

Initial proposal for short-term release process

5f834dd

jacderida requested a review from a team as a code owner July 8, 2024 23:10