<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 14, 2018 at 5:40 PM, Shyam Ranganathan <span dir="ltr">&lt;<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>&gt;</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/14/2018 07:04 PM, Joe Julian wrote:<br>
&gt;<br>
&gt;<br>
&gt; On 03/14/2018 02:25 PM, Vijay Bellur wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Mar 13, 2018 at 4:25 AM, Kaleb S. KEITHLEY<br>
</span><div><div class="h5">&gt;&gt; &lt;<a href="mailto:kkeithle@redhat.com">kkeithle@redhat.com</a> &lt;mailto:<a href="mailto:kkeithle@redhat.com">kkeithle@redhat.com</a>&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;     On 03/12/2018 02:32 PM, Shyam Ranganathan wrote:<br>
&gt;&gt;     &gt; On 03/12/2018 10:34 AM, Atin Mukherjee wrote:<br>
&gt;&gt;     &gt;&gt;       *<br>
&gt;&gt;     &gt;&gt;<br>
&gt;&gt;     &gt;&gt;         After 4.1, we want to move to either continuous<br>
&gt;&gt;     numbering (like<br>
&gt;&gt;     &gt;&gt;         Fedora), or time based (like ubuntu etc) release<br>
&gt;&gt;     numbers. Which<br>
&gt;&gt;     &gt;&gt;         is the model we pick is not yet finalized. Happy to<br>
&gt;&gt;     hear opinions.<br>
&gt;&gt;     &gt;&gt;<br>
&gt;&gt;     &gt;&gt;<br>
&gt;&gt;     &gt;&gt; Not sure how the time based release numbers would make more<br>
&gt;&gt;     sense than<br>
&gt;&gt;     &gt;&gt; the one which Fedora follows. But before I comment further on<br>
&gt;&gt;     this I<br>
&gt;&gt;     &gt;&gt; need to first get a clarity on how the op-versions will be<br>
&gt;&gt;     managed. I&#39;m<br>
&gt;&gt;     &gt;&gt; assuming once we&#39;re at GlusterFS 4.1, post that the releases<br>
&gt;&gt;     will be<br>
&gt;&gt;     &gt;&gt; numbered as GlusterFS5, GlusterFS6 ... So from that<br>
&gt;&gt;     perspective, are we<br>
&gt;&gt;     &gt;&gt; going to stick to our current numbering scheme of op-version<br>
&gt;&gt;     where for<br>
&gt;&gt;     &gt;&gt; GlusterFS5 the op-version will be 50000?<br>
&gt;&gt;     &gt;<br>
&gt;&gt;     &gt; Say, yes.<br>
&gt;&gt;     &gt;<br>
&gt;&gt;     &gt; The question is why tie the op-version to the release number? That<br>
&gt;&gt;     &gt; mental model needs to break IMO.<br>
&gt;&gt;     &gt;<br>
&gt;&gt;     &gt; With current options like,<br>
&gt;&gt;     &gt; <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><br>
&gt;&gt;     &lt;<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>&gt; it is<br>
&gt;&gt;     &gt; easier to determine the op-version of the cluster and what it<br>
&gt;&gt;     should be,<br>
&gt;&gt;     &gt; and hence this need not be tied to the gluster release version.<br>
&gt;&gt;     &gt;<br>
&gt;&gt;     &gt; Thoughts?<br>
&gt;&gt;<br>
&gt;&gt;     I&#39;m okay with that, but——<br>
&gt;&gt;<br>
&gt;&gt;     Just to play the Devil&#39;s Advocate, having an op-version that bears<br>
&gt;&gt;     some<br>
&gt;&gt;     resemblance to the _version_ number may make it easy/easier to<br>
&gt;&gt;     determine<br>
&gt;&gt;     what the op-version ought to be.<br>
&gt;&gt;<br>
&gt;&gt;     We aren&#39;t going to run out of numbers, so there&#39;s no reason to be<br>
&gt;&gt;     &quot;efficient&quot; here. Let&#39;s try to make it easy. (Easy to not make a<br>
&gt;&gt;     mistake.)<br>
&gt;&gt;<br>
&gt;&gt;     My 2¢<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; +1 to the overall release cadence change proposal and what Kaleb<br>
&gt;&gt; mentions here. <br>
&gt;&gt;<br>
&gt;&gt; Tying op-versions to release numbers seems like an easier approach<br>
&gt;&gt; than others &amp; one to which we are accustomed to. What are the benefits<br>
&gt;&gt; of breaking this model?<br>
&gt;&gt;<br>
&gt; There is a bit of confusion among the user base when a release happens<br>
&gt; but the op-version doesn&#39;t have a commensurate bump. People ask why they<br>
&gt; can&#39;t set the op-version to match the gluster release version they have<br>
&gt; installed. If it was completely disconnected from the release version,<br>
&gt; that might be a great enough mental disconnect that the expectation<br>
&gt; could go away which would actually cause less confusion.<br>
<br>
</div></div>Above is the reason I state it as well (the breaking of the mental model<br>
around this), why tie it together when it is not totally related. I also<br>
agree that, the notion is present that it is tied together and hence<br>
related, but it may serve us better to break it.<br><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div><br></div><div>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.</div><div><br></div><div>To make everyone&#39;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:</div><div><br></div><div>op-version X: 3.7.0 to 3.7.11</div><div>op-version Y: 3.7.12 to x.y.z</div><div><br></div><div>and so on.</div><div><br></div><div>Thanks,</div><div>Vijay</div></div></div></div>