<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 03/14/2018 02:25 PM, Vijay Bellur
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHn=sVDKZSLEmmemGcgUUJYxxATk=Z020Wff4=wG459wxAOJmA@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 13, 2018 at 4:25 AM,
Kaleb S. KEITHLEY <span dir="ltr"><<a
href="mailto:kkeithle@redhat.com" target="_blank"
moz-do-not-send="true">kkeithle@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 03/12/2018 02:32 PM, Shyam Ranganathan
wrote:<br>
> On 03/12/2018 10:34 AM, Atin Mukherjee wrote:<br>
>> *<br>
>><br>
>> After 4.1, we want to move to either
continuous numbering (like<br>
>> Fedora), or time based (like ubuntu
etc) release numbers. Which<br>
>> is the model we pick is not yet
finalized. Happy to hear opinions.<br>
>><br>
>><br>
>> Not sure how the time based release numbers
would make more sense than<br>
>> the one which Fedora follows. But before I
comment further on this I<br>
>> need to first get a clarity on how the
op-versions will be managed. I'm<br>
>> assuming once we're at GlusterFS 4.1, post that
the releases will be<br>
>> numbered as GlusterFS5, GlusterFS6 ... So from
that perspective, are we<br>
>> going to stick to our current numbering scheme
of op-version where for<br>
>> GlusterFS5 the op-version will be 50000?<br>
><br>
> Say, yes.<br>
><br>
> The question is why tie the op-version to the
release number? That<br>
> mental model needs to break IMO.<br>
><br>
> With current options like,<br>
> <a
href="https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://docs.gluster.org/en/<wbr>latest/Upgrade-Guide/op_<wbr>version/</a>
it is<br>
> easier to determine the op-version of the cluster
and what it should be,<br>
> and hence this need not be tied to the gluster
release version.<br>
><br>
> Thoughts?<br>
<br>
</span>I'm okay with that, but——<br>
<br>
Just to play the Devil's Advocate, having an op-version
that bears some<br>
resemblance to the _version_ number may make it
easy/easier to determine<br>
what the op-version ought to be.<br>
<br>
We aren't going to run out of numbers, so there's no
reason to be<br>
"efficient" here. Let's try to make it easy. (Easy to not
make a mistake.)<br>
<br>
My 2¢<br>
<br>
</blockquote>
<div><br>
</div>
<div>+1 to the overall release cadence change proposal and
what Kaleb mentions here. </div>
<div><br>
</div>
<div>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?</div>
<br>
</div>
</div>
</div>
</blockquote>
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.<br>
</body>
</html>