[Gluster-devel] [Gluster-Maintainers] Proposal to change the version numbers of Gluster project
Shyam Ranganathan
srangana at redhat.com
Thu Mar 15 10:39:37 UTC 2018
On 03/15/2018 12:48 AM, Atin Mukherjee wrote:
>
>
> On Thu, Mar 15, 2018 at 9:45 AM, Vijay Bellur <vbellur at redhat.com
> <mailto:vbellur at redhat.com>> wrote:
>
>
>
> On Wed, Mar 14, 2018 at 5:40 PM, Shyam Ranganathan
> <srangana at redhat.com <mailto:srangana at redhat.com>> wrote:
>
> On 03/14/2018 07:04 PM, Joe Julian wrote:
> >
> >
> > 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>
> <mailto: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/>
> >>
> <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.
>
> Above is the reason I state it as well (the breaking of the
> mental model
> around this), why tie it together when it is not totally
> related. I also
> agree that, the notion is present that it is tied together and hence
> related, but it may serve us better to break it.
>
>
>
> I see your perspective. Another related reason for not introducing
> an op-version bump in a new release would be that there are no
> incompatible features introduced (in the new release). Hence it
> makes sense to preserve the older op-version.
>
> To make everyone's lives simpler, would it be useful to introduce a
> command that provides the max op-version to release number mapping?
> The output of the command could look like:
>
> op-version X: 3.7.0 to 3.7.11
> op-version Y: 3.7.12 to x.y.z
>
>
> We already have introduced an option called cluster.max-op-version where
> one can run a command like "gluster v get all cluster.max-op-version" to
> determine what highest op-version the cluster can be bumped up to. IMO,
> this helps users not to look at the document for at given x.y.z release
> the op-version has to be bumped up to XXXXX . Isn't that sufficient for
> this requirement?
jFYI, this is also captured in the op-version upgrade-guide document
(link as posted earlier:
https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/ )
>
>
>
> and so on.
>
> Thanks,
> Vijay
>
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org <mailto:maintainers at gluster.org>
> http://lists.gluster.org/mailman/listinfo/maintainers
> <http://lists.gluster.org/mailman/listinfo/maintainers>
>
>
More information about the Gluster-devel
mailing list