Release Process

• URL: https://github.com/Patternslib/Patterns/wiki/Release-Process
• Defined in: https://github.com/Patternslib/Patterns/issues/1090
• Obsoletes: https://github.com/Patternslib/Patterns/issues/1012

Better Patternslib Release Handling

Goals

• The patterns website should always contain the latest stable patterns release, to not scare users with aphas and betas. Because based only on the release notes, end users can probably not take a decision whether they should use them anyway. (and the current 4.2.4 is way too old).

• The prototype stakeholder (Cornelis) should be able to decide on his own what bundle to include into prototype. (Drop in)

• The Ploneintranet/Euphorie development team should be able to test new features from Patternslib without the prototype stakeholder first approve a Patternslib release as stable.

Release Process

• New patternslib 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 test it in-depth, we declare a feature freeze. From then on only bug fixes are made. These stabilization releases are marked as beta, e.g. 8.1.0b1, 8.1.0b2 etc. The Patternslib stabilization/feature freeze phase is started just before we want to make a release for Quaive or Euphorie when we start a feature freeze phase for those.

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

Integrating releases into prototypes

• As soon as a alpha/beta/final release is done, the prototype stakeholder is informed about that.

• The prototype stakeholder can then integrate the bundle into prototype on his/her own and test the bundle.

Available options to integrate the bundle are:

• Downloading and unpacking the bundle zip file from GitHub (There is a make update-patterns in oira.prototype which does that automatically).

• Using the CDN which is configured in _config-dev.yml by starting the server with make devserve.

Integrating pre-releases into Quaive/Euphorie development

The (future) releases of Patternslib also contain the compiled bundles. These Bundles can be referenced via official CDNs like so: https://cdn.jsdelivr.net/npm/@patternslib/[email protected]/dist/bundle.min.js or https://unpkg.com/@patternslib/[email protected]/dist/bundle.min.js Instead of a version specifier we can also use the tags latest, alpha or beta.

Preconditions:

• We do not need to ship redactor (closed source) anymore.

• To integrate a Patternslib pre-release we change the viewlet which adds the <script> tag to allow to include the resource from any URL.

Process:

• When the instance is started in foreground mode - so, when Zope is in development mode - the viewlet would include the resource a CDN url defined in a registry setting. The default would still be to include the resource from quaive.resources.ploneintranet.

• The Ploneintranet testing deployments where Zope is not in development mode the instance would read a development registry setting to use the configured CDN instead of the relesed default resources.

• The Ploneintranet production releases where Zope is not in development mode the resource would use the released default resources from QRP. For this we need to reset the development registry setting.

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.