[Gluster-devel] Idea: Alternate Release process
Aravinda
avishwan at redhat.com
Thu May 5 06:18:26 UTC 2016
Hi,
Sharing an idea to manage multiple releases without maintaining
multiple release branches and backports.
This idea is heavily inspired by the Rust release model(you may feel
exactly same except the LTS part). I think Chrome/Firefox also follows
the same model.
http://blog.rust-lang.org/2014/10/30/Stability.html
Feature Flag:
--------------
Compile time variable to prevent compiling featurerelated code when
disabled. (For example, ./configure--disable-geo-replication
or ./configure --disable-xml etc)
Plan
-----
- Nightly build with all the features enabled(./build --nightly)
- All new patches will land in Master, if the patch belongs to a
existing feature then it should be written behind that feature flag.
- If a feature is still work in progress then it will be only enabled in
nightly build and not enabled in beta or stable builds.
Once the maintainer thinks the feature is ready for testing then that
feature will be enabled in beta build.
- Every 6 weeks, beta branch will be created by enabling all the
features which maintainers thinks it is stable and previous beta
branch will be promoted as stable.
All the previous beta features will be enabled in stable unless it
is marked as unstable during beta testing.
- LTS builds are same as stable builds but without enabling all the
features. If we decide last stable build will become LTS release,
then the feature list from last stable build will be saved as
`features-release-<NUM>.yaml`, For example:
features-release-3.9.yaml`
Same feature list will be used while building minor releases for the
LTS. For example, `./build --stable --features features-release-3.8.yaml`
- Three branches, nightly/master, testing/beta, stable
To summarize,
- One stable release once in 6 weeks
- One Beta release once in 6 weeks
- Nightly builds every day
- LTS release once in 6 months or 1 year, Minor releases once in 6 weeks.
Advantageous:
-------------
1. No more backports required to different release branches.(only
exceptional backports, discussed below)
2. Non feature Bugfix will never get missed in releases.
3. Release process can be automated.
4. Bugzilla process can be simplified.
Challenges:
------------
1. Enforcing Feature flag for every patch
2. Tests also should be behind feature flag
3. New release process
Backports, Bug Fixes and Features:
----------------------------------
- Release bug fix - Patch only to Master, which will be available in
next beta/stable build.
- Urgent bug fix - Patch to Master and Backport to beta and stable
branch, and early release stable and beta build.
- Beta bug fix - Patch to Master and Backport to Beta branch if urgent.
- Security fix - Patch to Master, Beta and last stable branch and build
all LTS releases.
- Features - Patch only to Master, which will be available in
stable/beta builds once feature becomes stable.
FAQs:
-----
- Can a feature development take more than one release cycle(6 weeks)?
Yes, the feature will be enabled only in nightly build and not in
beta/stable builds. Once the feature is complete mark it as
stable so that it will be included in next beta build and stable
build.
---
Do you like the idea? Let me know what you guys think.
--
regards
Aravinda
More information about the Gluster-devel
mailing list