[Gluster-devel] Proposal to change the version numbers of Gluster project
atumball at redhat.com
Mon Mar 12 12:21:26 UTC 2018
Below is the proposal which most of us in maintainers list have agreed
upon. Sharing it here so we come to conclusion quickly, and move on :-)
Until now, Gluster project’s releases followed x.y.z model, where x is
indicating a major revision, and y a minor, and z as a patched release.
Read more on this model at wikipedia
As we are announcing the release and availability of Gluster 4.0[.0] now,
it is a good time to reconsider our version numbering.
is the need to reconsider version number now?
The major and minor version numbering is a good strategy for projects which
would bring incompatibility between major versions.
For Gluster, as it is a filesystem, and one of the major reason people use
this project is because of ‘High Availability’, we can never think of
breaking compatibility between releases. So, regardless of any major
version changes, the filesystem should continue to work from a given mount
*NOTE*: We are not saying there will be no issues ever for clients at all,
but users will have enough time to plan, based on called out
incompatabilities, and hence adapt to the new changes in an application
Also, this allows us to bring features and changes frequently, and not wait
for the major version number change to make a release.
<https://hackmd.io/os2Kmd6iTpuG4hO6Qcvc2A?both#So-what-next>So, what next?
There are multiple changes we are proposing.
As announced earlier 4.0 will be STM, and it will be the last STM.
As we had already announced, 4.1 will be our LTM (Long Term Maintenance)
release. This will release 3 months from 4.0 (June, 2018 end)
After 4.1, we want to move to either continuous numbering (like Fedora),
or time based (like ubuntu etc) release numbers. Which is the model we pick
is not yet finalized. Happy to hear opinions.
There will be no more STM releases for early access, still to mature
features. We will either use the experimental branch, or tag a feature
in a release as experimental. Everything core to the operation of Gluster,
will remain stable and will only improve from release to release.
*NOTE:* Exact mechanisims for tagging something experimental Vs stable is
being evolved. Further, what this means for a user is also being evovled
and will be put out for discussion soon.
Considering we had 6 months release cycle for LTM releases, and 3 months
for branching, we want to fall back to 4 months release cycle for different
versions, so we will cut down on number of backports, and supported
versions from which we can upgrade to latest. Also users will benefit from
more releases which are going to be supported long term.
Every release will be maintained for 1 year as earlier
- Monthly bug fixs per maintained release would be made available (as
before) (update releases)
- Post the first 3 or 4 months, for monthly bug fix update releases,
the cycle will change to bi-monthy (once in 2 months) or expidated as
Happy to hear your opinion.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel