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_ > it isversion/
>> > 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.
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
and so on.
Thanks,
Vijay
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
