Feature Proposal: Clarify the core extension release process.
Motivation
Recently some core extensions have been released to the Extensions web. These have resulted in some site breakage, where site administrators assumed that the red highlighted "Needs upgrade" alert in configure implied that the extension should be updated.
See:
Although the release process is very specific on how new features and major modifications make it into a new release, it doesn't really address:
- How and when a new release is built.
- Testing stages, such as alpha, beta, installation on foswiki.org, release candidates, etc.
- How and when an extension that follows the release process can be released in between Foswiki releases.
- The decision making process that determines when a new version of core or core extension is "ready for release"
To ensure the highest code quality, this needs to be specified.
Description and Documentation
The purpose of this proposal is to clarify the process for core and core extension releases. Much of the below documents the process followed by Foswiki 1.1.4 and 1.1.5.
Foswiki Releases
- Release process requires that either all Urgent tasks have been resolved, or consensus is reached that the task can be deferred, or have its priority reduced.
- How is the decision to defer or reduce priority of a task made?
- Release process may include
- Private beta for testing on Foswiki.org
- Public beta
- Release candidate
- Release candidates become the next release without change
- If changes are required, another release candidate should be built
- All public code should be installed on Foswiki.org before being made available.
- The release and all default extensions are built from the same branch.
- Extensions should never be mixed across branches.
- Extension version numbers don't track the core release, but they should be incremented if changes have been made.
- Extensions are only uploaded to Extensions web once the final release has been released.
- Extensions may be uploaded to Extensions/Testing web as part of beta / RC testing.
Core Extensions - interim releases
Occasionally it's necessary to release a core extension without the overhead of building a complete foswiki release. Core extensions however still must follow the release process; New features and significant changes must go through the feature proposal process.
- Interim releases generally should be for bug fixes.
- New features and major changes need to follow the feature proposal process
- Major changes should only be made after obtaining consensus from the Foswiki community
- Interim releases of Core extensions must always be built from the same branch as the release.
- Versions from other branches or trunk must never be uploaded to the Extensions web.
- As best as possible, interim releases of core extensions should follow the core release process
- Build a test package, beta, release candidate, etc.
- Release to the Extensions/Testing web
- Install on Foswiki.org for a reasonable test period.
Emergency Releases
In the event of a security vulnerability or other urgent issue that requires an immediate release:
- Fixes should be made against the last release tag. Other unrelated changes should not be rushed out to deal with the urgent need.
- A brief beta or test period should still be staged on foswiki.org.
Examples
Impact
Implementation
--
Contributors: GeorgeClark - 19 Jul 2012
Discussion
Thanks for doing this George. The main point is that we should not release from trunk; always release from Rel branches.
--
PaulHarvey - 19 Jul 2012 - 05:23
Also, release of core extensions should be treated much more carefully with thorough testing for good compatibility with older releases. The core extensions reflect very much on the quality and reputation of Foswiki.
--
GeorgeClark - 19 Jul 2012
Changing this to merged to core. This is just procedural documentation.
--
GeorgeClark - 19 Nov 2015