[Gluster-devel] Proposal to change the version numbers of Gluster project

[Amar Tumballi]

Hi all,

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
<https://en.wikipedia.org/wiki/Software_versioning#Change_significance>

As we are announcing the release and availability of Gluster 4.0[.0] now,
it is a good time to reconsider our version numbering.
<https://hackmd.io/os2Kmd6iTpuG4hO6Qcvc2A?both#What-is-the-need-to-reconsider-version-number-now>What
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
point.

*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
maintenance window.

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
      necessary

---

Happy to hear your opinion.


Regards,
Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180312/ca281ec6/attachment-0001.html>