|
+1 Proposed alternative 2 - One LTS every year and non LTS stable
release once in every 3 months
On 13/05/16 13:46, Aravinda wrote:
Hi,
Based on the discussion in last community meeting and previous
discussions,
1. Too frequent releases are difficult to manage.(without
dedicated release manager)
2. Users wants to see features early for testing or POC.
3. Backporting patches to more than two release branches is pain
Enclosed visualizations to understand existing release and
support cycle and proposed alternatives.
- Each grid interval is 6 months
- Green rectangle shows supported release or LTS
- Black dots are minor releases till it is supported(once a
month)
- Orange rectangle is non LTS release with minor
releases(Support ends when next version released)
Enclosed following images
1. Existing Release cycle and support plan(6 months release
cycle, 3 releases supported all the time)
2. Proposed alternative 1 - One LTS every year and non LTS
stable release once in every 2 months
3. Proposed alternative 2 - One LTS every year and non LTS
stable release once in every 3 months
4. Proposed alternative 3 - One LTS every year and non LTS
stable release once in every 4 months
5. Proposed alternative 4 - One LTS every year and non LTS
stable release once in every 6 months (Similar to existing but
only alternate one will become LTS)
Please do vote for the proposed alternatives about release
intervals and LTS releases. You can also vote for the existing
plan.
Do let me know if I missed anything.
regards
Aravinda
On 05/11/2016 12:01 AM, Aravinda
wrote:
I couldn't find any solution for the backward incompatible
changes. As you mentioned this model will not work for LTS.
How about adopting this only for non LTS releases? We will
not have backward incompatibility problem since we need not
release minor updates to non LTS releases.
regards
Aravinda
On 05/05/2016 04:46 PM, Aravinda
wrote:
regards
Aravinda
On 05/05/2016 03:54 PM, Kaushal M wrote:
On Thu, May 5, 2016 at 11:48 AM,
Aravinda <avishwan@xxxxxxxxxx>
wrote:
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.
This reduces the number of versions that we need to
maintain, which I like.
Having official test (beta) releases should help get
features out to
testers hand faster,
and get quicker feedback.
One thing that's still not quite clear to is the issue of
backwards
compatibility.
I'm still thinking it thorough and don't have a proper
answer to this yet.
Would a new release be backwards compatible with the
previous release?
Should we be maintaining compatibility with LTS releases
with the
latest release?
Each LTS release will have seperate list of features to be
enabled. If we make any breaking changes(which are not
backward compatible) then it will affect LTS releases as you
mentioned. But we should not break compatibility unless it is
major version change like 4.0. I have to workout how we can
handle backward incompatible changes.
With our current strategy, we at least
have a long term release branch,
so we get some guarantees of compatibility with releases on
the same branch.
As I understand the proposed approach, we'd be replacing a
stable
branch with the beta branch.
So we don't have a long-term release branch (apart from
LTS).
Stable branch is common for LTS releases also. Builds will be
different using different list of features.
Below example shows stable release once in 6 weeks, and two
LTS releases in 6 months gap(3.8 and 3.12)
LTS 1 : 3.8 3.8.1 3.8.2 3.8.3 3.8.4 3.8.5...
LTS 2 : 3.12 3.12.1...
Stable: 3.8 3.9 3.10 3.11 3.12 3.13...
A user would be upgrading from one
branch to another for every release.
Can we sketch out how compatibility would work in this case?
User will not upgrade from one branch to other branch, If user
interested in stable channel then upgrade once in 6 weeks.
(Same as minor update in current release style)
This approach work well for projects like Chromium and
Firefox, single
system apps
which generally don't need to be compatible with the
previous release.
I don't understand how the Rust project uses this (I am yet
to read
the linked blog post),
as it requires some sort of backwards compatibility. But it
too is a
single system app,
and doesn't have the compatibility problems we face.
Gluster is a distributed system, that can involve multiple
different
versions interacting with each other.
This is something we need to think about.
I need to think about compatibility, What new problems about
the compatibility with this approach compared to our existing
release plan?
We could work out some sort of a solution for this though.
It might be something very obvious I'm missing right now.
~kaushal
--
regards
Aravinda
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
|
