<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 May 2016 at 13:46, Aravinda <span dir="ltr">&lt;<a href="mailto:avishwan@redhat.com" target="_blank">avishwan@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">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <tt>Hi,<br>
      <br>
      Based on the discussion in last community meeting and previous
      discussions,<br>
      <br>
      1. Too frequent releases are difficult to manage.(without
      dedicated release manager)<br>
      2. Users wants to see features early for testing or POC.<br>
      3. Backporting patches to more than two release branches is pain<br>
      <br>
      Enclosed visualizations to understand existing release and support
      cycle and proposed alternatives.<br>
      <br>
      - Each grid interval is 6 months<br>
      - Green rectangle shows supported release or LTS<br>
      - Black dots are minor releases till it is supported(once a month)<br>
      - Orange rectangle is non LTS release with minor releases(Support
      ends when next version released)<br>
      <br>
      Enclosed following images<br>
      1. Existing Release cycle and support plan(6 months release cycle,
      3 releases supported all the time)<br>
      2. Proposed alternative 1 - One LTS every year and non LTS stable
      release once in every 2 months<br>
      3. Proposed alternative 2 - One LTS every year and non LTS stable
      release once in every 3 months<br></tt></div></blockquote><div><br></div><div>+1 for 3rd option. non-LTS stable release on every three months.</div><div><br></div><div>Best Regards,</div><div>Vishwanath</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><tt>
      4. Proposed alternative 3 - One LTS every year and non LTS stable
      release once in every 4 months<br>
      5. Proposed alternative 4 - One LTS every year and non LTS stable
      release once in every 6 months (Similar to existing but only
      alternate one will become LTS)<br>
      <br>
      Please do vote for the proposed alternatives about release
      intervals and LTS releases. You can also vote for the existing
      plan.<br>
      <br>
      Do let me know if I missed anything.<br>
    </tt>
    <pre cols="72">regards
Aravinda</pre><div><div class="h5">
    <div>On 05/11/2016 12:01 AM, Aravinda wrote:<br>
    </div>
    <blockquote type="cite">
      
      <p>I couldn&#39;t find any solution for the backward incompatible
        changes. As you mentioned this model will not work for LTS.</p>
      <p>How about adopting this only for non LTS releases? We will not
        have backward incompatibility problem since we need not release
        minor updates to non LTS releases.<br>
      </p>
      <pre cols="72">regards
Aravinda</pre>
      <div>On 05/05/2016 04:46 PM, Aravinda
        wrote:<br>
      </div>
      <blockquote type="cite"> <br>
        regards <br>
        Aravinda <br>
        <br>
        On 05/05/2016 03:54 PM, Kaushal M wrote: <br>
        <blockquote type="cite">On Thu, May 5, 2016 at 11:48 AM,
          Aravinda <a href="mailto:avishwan@redhat.com" target="_blank">&lt;avishwan@redhat.com&gt;</a>
          wrote: <br>
          <blockquote type="cite">Hi, <br>
            <br>
            Sharing an idea to manage multiple releases without
            maintaining <br>
            multiple release branches and backports. <br>
            <br>
            This idea is heavily inspired by the Rust release model(you
            may feel <br>
            exactly same except the LTS part). I think Chrome/Firefox
            also follows <br>
            the same model. <br>
            <br>
            <a href="http://blog.rust-lang.org/2014/10/30/Stability.html" target="_blank">http://blog.rust-lang.org/2014/10/30/Stability.html</a>
            <br>
            <br>
            Feature Flag: <br>
            -------------- <br>
            Compile time variable to prevent compiling featurerelated
            code when <br>
            disabled. (For example, ./configure--disable-geo-replication
            <br>
            or ./configure --disable-xml etc) <br>
            <br>
            Plan <br>
            ----- <br>
            - Nightly build with all the features enabled(./build
            --nightly) <br>
            <br>
            - All new patches will land in Master, if the patch belongs
            to a <br>
               existing feature then it should be written behind that
            feature flag. <br>
            <br>
            - If a feature is still work in progress then it will be
            only enabled in <br>
               nightly build and not enabled in beta or stable builds. <br>
               Once the maintainer thinks the feature is ready for
            testing then that <br>
               feature will be enabled in beta build. <br>
            <br>
            - Every 6 weeks, beta branch will be created by enabling all
            the <br>
               features which maintainers thinks it is stable and
            previous beta <br>
               branch will be promoted as stable. <br>
               All the previous beta features will be enabled in stable
            unless it <br>
               is marked as unstable during beta testing. <br>
            <br>
            - LTS builds are same as stable builds but without enabling
            all the <br>
               features. If we decide last stable build will become LTS
            release, <br>
               then the feature list from last stable build will be
            saved as <br>
               `features-release-&lt;NUM&gt;.yaml`, For example: <br>
               features-release-3.9.yaml` <br>
               Same feature list will be used while building minor
            releases for the <br>
               LTS. For example, `./build --stable --features
            features-release-3.8.yaml` <br>
            <br>
            - Three branches, nightly/master, testing/beta, stable <br>
            <br>
            To summarize, <br>
            - One stable release once in 6 weeks <br>
            - One Beta release once in 6 weeks <br>
            - Nightly builds every day <br>
            - LTS release once in 6 months or 1 year, Minor releases
            once in 6 weeks. <br>
            <br>
            Advantageous: <br>
            ------------- <br>
            1. No more backports required to different release
            branches.(only <br>
                exceptional backports, discussed below) <br>
            2. Non feature Bugfix will never get missed in releases. <br>
            3. Release process can be automated. <br>
            4. Bugzilla process can be simplified. <br>
            <br>
            Challenges: <br>
            ------------ <br>
            1. Enforcing Feature flag for every patch <br>
            2. Tests also should be behind feature flag <br>
            3. New release process <br>
            <br>
            Backports, Bug Fixes and Features: <br>
            ---------------------------------- <br>
            - Release bug fix - Patch only to Master, which will be
            available in <br>
               next beta/stable build. <br>
            - Urgent bug fix - Patch to Master and Backport to beta and
            stable <br>
               branch, and early release stable and beta build. <br>
            - Beta bug fix - Patch to Master and Backport to Beta branch
            if urgent. <br>
            - Security fix - Patch to Master, Beta and last stable
            branch and build <br>
               all LTS releases. <br>
            - Features - Patch only to Master, which will be available
            in <br>
               stable/beta builds once feature becomes stable. <br>
            <br>
            FAQs: <br>
            ----- <br>
            - Can a feature development take more than one release
            cycle(6 weeks)? <br>
            Yes, the feature will be enabled only in nightly build and
            not in <br>
            beta/stable builds. Once the feature is complete mark it as
            <br>
            stable so that it will be included in next beta build and
            stable <br>
            build. <br>
            <br>
            <br>
            --- <br>
            <br>
            Do you like the idea? Let me know what you guys think. <br>
            <br>
          </blockquote>
          This reduces the number of versions that we need to maintain,
          which I like. <br>
          Having official test (beta) releases should help get features
          out to <br>
          testers hand faster, <br>
          and get quicker feedback. <br>
          <br>
          One thing that&#39;s still not quite clear to is the issue of
          backwards <br>
          compatibility. <br>
          I&#39;m still thinking it thorough and don&#39;t have a proper answer
          to this yet. <br>
          Would a new release be backwards compatible with the previous
          release? <br>
          Should we be maintaining compatibility with LTS releases with
          the <br>
          latest release? <br>
        </blockquote>
        Each LTS release will have seperate list of features to be
        enabled. If we make any breaking changes(which are not backward
        compatible) then it will affect LTS releases as you mentioned.
        But we should not break compatibility unless it is major version
        change like 4.0. I have to workout how we can handle backward
        incompatible changes. <br>
        <br>
        <blockquote type="cite">With our current strategy, we at least
          have a long term release branch, <br>
          so we get some guarantees of compatibility with releases on
          the same branch. <br>
          <br>
          As I understand the proposed approach, we&#39;d be replacing a
          stable <br>
          branch with the beta branch. <br>
          So we don&#39;t have a long-term release branch (apart from LTS).
          <br>
        </blockquote>
        Stable branch is common for LTS releases also. Builds will be
        different using different list of features. <br>
        <br>
        Below example shows stable release once in 6 weeks, and two LTS
        releases in 6 months gap(3.8 and 3.12) <br>
        <br>
        LTS 1 : 3.8    3.8.1  3.8.2  3.8.3   3.8.4   3.8.5... <br>
        LTS 2 :                              3.12    3.12.1... <br>
        Stable: 3.8    3.9    3.10   3.11    3.12    3.13... <br>
        <blockquote type="cite">A user would be upgrading from one
          branch to another for every release. <br>
          Can we sketch out how compatibility would work in this case? <br>
        </blockquote>
        User will not upgrade from one branch to other branch, If user
        interested in stable channel then upgrade once in 6 weeks. (Same
        as minor update in current release style) <br>
        <blockquote type="cite"> <br>
          This approach work well for projects like Chromium and
          Firefox, single <br>
          system apps <br>
            which generally don&#39;t need to be compatible with the
          previous release. <br>
          I don&#39;t understand how the Rust  project uses this (I am yet
          to read <br>
          the linked blog post), <br>
          as it requires some sort of backwards compatibility. But it
          too is a <br>
          single system app, <br>
          and doesn&#39;t have the compatibility problems we face. <br>
          <br>
          Gluster is a distributed system, that can involve multiple
          different <br>
          versions interacting with each other. <br>
          This is something we need to think about. <br>
        </blockquote>
        I need to think about compatibility, What new problems about the
        compatibility with this approach compared to our existing
        release plan? <br>
        <blockquote type="cite"> <br>
          We could work out some sort of a solution for this though. <br>
          It might be something very obvious I&#39;m missing right now. <br>
          <br>
          ~kaushal <br>
          <br>
          <blockquote type="cite">-- <br>
            regards <br>
            Aravinda <br>
            <br>
            _______________________________________________ <br>
            Gluster-devel mailing list <br>
            <a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a>
            <br>
            <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
            <br>
          </blockquote>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br></blockquote></div><br></div></div>