<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">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">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><div><br></div><div>Thanks,</div><div>Vijay </div></div></div></div>