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

[Atin Mukherjee]

On Mon, Mar 12, 2018 at 5:51 PM, Amar Tumballi <atumball at redhat.com> 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
> <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.
>
>
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 at gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180312/1bb5b27c/attachment.html>