Re: [Gluster-Maintainers] Proposal to change the version numbers of Gluster project

[Atin Mukherjee <amukherj@xxxxxxxxxx>]

On Mon, Mar 12, 2018 at 5:51 PM, Amar Tumballi <atumball@xxxxxxxxxx> wrote:

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

As we are announcing the release and availability of Gluster 4.0[.0] now, it is a good time to reconsider our version numbering.

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.

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.

Not sure how the time based release numbers would make more sense than the one which Fedora follows. But before I comment further on this I need to first get a clarity on how the op-versions will be managed. I'm assuming once we're at GlusterFS 4.1, post that the releases will be numbered as GlusterFS5, GlusterFS6 ... So from that perspective, are we going to stick to our current numbering scheme of op-version where for GlusterFS5 the op-version will be 50000?
 

• 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

_______________________________________________
maintainers mailing list
maintainers@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/maintainers

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel