On Thu, Mar 15, 2018 at 9:45 AM, Vijay Bellur <vbellur@xxxxxxxxxx> wrote:
On Wed, Mar 14, 2018 at 5:40 PM, Shyam Ranganathan <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
Above is the reason I state it as well (the breaking of the mental model>> <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_versio > it isn/
>> > 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.
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.
Yes. I think it may not be a good idea to introduce an artificial incompatibility when there is none. Probably serves us better if op-versions are mirroring what they are supposed to do.
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.11op-version Y: 3.7.12 to x.y.zand so on.Thanks,Vijay
_______________________________________________
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
