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

[Joe Julian]

On 03/14/2018 02:25 PM, Vijay Bellur wrote:
>
>
> On Tue, Mar 13, 2018 at 4:25 AM, Kaleb S. KEITHLEY 
> <kkeithle at redhat.com <mailto:kkeithle at redhat.com>> wrote:
>
>     On 03/12/2018 02:32 PM, Shyam Ranganathan wrote:
>     > On 03/12/2018 10:34 AM, Atin Mukherjee wrote:
>     >>       *
>     >>
>     >>         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?
>     >
>     > Say, yes.
>     >
>     > The question is why tie the op-version to the release number? That
>     > mental model needs to break IMO.
>     >
>     > With current options like,
>     > https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/
>     <https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/> it is
>     > easier to determine the op-version of the cluster and what it
>     should be,
>     > and hence this need not be tied to the gluster release version.
>     >
>     > Thoughts?
>
>     I'm okay with that, but——
>
>     Just to play the Devil's Advocate, having an op-version that bears
>     some
>     resemblance to the _version_ number may make it easy/easier to
>     determine
>     what the op-version ought to be.
>
>     We aren't going to run out of numbers, so there's no reason to be
>     "efficient" here. Let's try to make it easy. (Easy to not make a
>     mistake.)
>
>     My 2¢
>
>
> +1 to the overall release cadence change proposal and what Kaleb 
> mentions here.
>
> Tying op-versions to release numbers seems like an easier approach 
> than others & one to which we are accustomed to. What are the benefits 
> of breaking this model?
>
There is a bit of confusion among the user base when a release happens 
but the op-version doesn't have a commensurate bump. People ask why they 
can't set the op-version to match the gluster release version they have 
installed. If it was completely disconnected from the release version, 
that might be a great enough mental disconnect that the expectation 
could go away which would actually cause less confusion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180314/4b2d599c/attachment.html>