On 03/15/2018 12:48 AM, Atin Mukherjee wrote: > > > On Thu, Mar 15, 2018 at 9:45 AM, Vijay Bellur <vbellur@xxxxxxxxxx > <mailto:vbellur@xxxxxxxxxx>> wrote: > > > > On Wed, Mar 14, 2018 at 5:40 PM, Shyam Ranganathan > <srangana@xxxxxxxxxx <mailto:srangana@xxxxxxxxxx>> 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@xxxxxxxxxx <mailto:kkeithle@xxxxxxxxxx> > <mailto:kkeithle@xxxxxxxxxx <mailto:kkeithle@xxxxxxxxxx>>> 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@xxxxxxxxxxx <mailto:maintainers@xxxxxxxxxxx> > http://lists.gluster.org/mailman/listinfo/maintainers > <http://lists.gluster.org/mailman/listinfo/maintainers> > > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
