Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better Release Management #1012

Closed
pilz opened this issue May 27, 2022 · 4 comments
Closed

Better Release Management #1012

pilz opened this issue May 27, 2022 · 4 comments
Assignees

Comments

@pilz
Copy link
Member

pilz commented May 27, 2022

URL: https://github.com/Patternslib/Patterns/wiki/Release-Process
Superseded by: #1090

OUTDATED

Better Patternslib Release Handling

  • The patterns website should always contain the latest stable patterns release, to… (4.2.4 is way too old).
  • Problem: We currently don't know what stable means.

Proposed Solution

  • New releases by default are development releases, marked as such with an alpha indicator, e.g. 8.1.0a1, 8.1.0a2 etc.
  • Once a release is stable enough to make it worthwhile to test it in-depth for production use, we declare a feature freeze. Henceforward only bug fixes are made. These stabilization releases are marked as beta, e.g. 8.1.0b1, 8.1.0b2 etc.
  • Only when all stakeholders agree the last beta is production ready, is it marked as a production release. All stakeholders here means: development + design + management. A production release is defined as not having an alpha or beta suffix number. The production release is done by re-releasing the latest beta with only a version bump, without any code changes. This then becomes 8.1.0.
  • When a new production release is made, the download button on the Patternslib website should be updated to point to this latest production release.

parallel work

Any invasive work or new feature work that needs to happen while a freeze is ongoing, should start a new version number alpha sequence. For example if we're stabilizing 8.1.0b7 and some new feature work needs to start, that would start on a branch and get released, from that branch, as 8.2.0a1, without main branch merge. The master merge only happens after the 8.1.0 series production release has been released. Alternatively, when you need parallel branches, the production preparation goes on a branch and main is used for ongoing development. As long as the production release sequence is not disrupted with development changes, either is fine.

@gyst gyst assigned gyst and thet and unassigned gyst May 27, 2022
@gyst
Copy link
Contributor

gyst commented May 27, 2022

@thet this is the write-up of the process we discussed.

@pilz
Copy link
Member Author

pilz commented May 27, 2022

The above ruleset applied to our current reality means the following:

  • Status quo: Our current released version is 8.0.3 - which is currently not to be considered stable
  • Hannes will from now only create releases marked as alpha (e.g. 8.0.4alpha) if he has something completed for demo purposes.
  • Once we have agreed on all work on close panel, scrollbox, displaytime, we will plan for a 8.1.0 stable release.
  • Once all features are in, we will release a 8.1.0beta1 package, signalling that it contains all planned features and that no new features, only bugfixes are added.
  • Once we have reached a state where everybody is happy with the state of the bundle, perhaps that might be 8.1.0beta5, we will re-release exactly that bundle as 8.1.0 and consider it stable.
  • We will release that on patternslib as well.

@JWl21 JWl21 closed this as completed May 31, 2022
@pilz
Copy link
Member Author

pilz commented May 31, 2022

@pilz
Copy link
Member Author

pilz commented May 31, 2022

Hannes is already releasing according to these rules. So we closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants