Details

    • Type: Task
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Do the work to EOL 0.96.

      + No more patches on 0.96
      + Remove 0.96 from downloads.
      + If user has issue with 0.96 and needs fix, fix it in 0.98 and have the user upgrade to get the fix.
      + Write email to user list stating 0.96 has been EOL'd September 1st? And add notice to refguide.

        Activity

        Hide
        stack stack added a comment -

        Add to doc., how to EOL a branch. We've not really done this before.

        Show
        stack stack added a comment - Add to doc., how to EOL a branch. We've not really done this before.
        Hide
        ishanc Ishan Chhabra added a comment -

        Is there a plan to EOL 0.94 soon as well?

        Show
        ishanc Ishan Chhabra added a comment - Is there a plan to EOL 0.94 soon as well?
        Hide
        stack stack added a comment -

        Lars Hofhansl Question for you above. Ishan Chhabra 0.96 will EOL before it does is how it is currently looking.

        Show
        stack stack added a comment - Lars Hofhansl Question for you above. Ishan Chhabra 0.96 will EOL before it does is how it is currently looking.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Ishan Chhabra In the end this an open source project. As long as there is a maintainer there'll be updates.

        The reasoning for retiring 0.96 is that everyone should rather go to 0.98 (you can do a rolling upgrade from 0.96 to 0.98, no data upgrade required).
        If we had semantic versioning going from 0.96 to 0.98 would something like going from version 2.0.x to 2.1.x (i.e. a minor version update). We're just saying: No more patches for the 2.0 code line, please upgrade to 2.1.x for bugfixes.

        0.94 is the prior major version. Retiring that in favor of 0.98 would be like going from 1.0.x to 2.x.y, with no rolling upgrades, no client-server protocol compatibility, and a data upgrade step and new version of Hadoop (likely) required.

        So we'd be maintaining the equivalent of 1.x.y, and 2.x.y.

        Eventually 0.94 will be retired (i.e. nobody will contribute patches to it any more). If we want save the work maintaining 0.94 or nobody is using it anymore anyway we can retire it soon. If we want to keep maintaining it for folks who cannot risk upgrading their data we can do so too.

        Why are you asking? You feel we should retire 0.94 as well? Or you're worried we might retire it?

        Show
        lhofhansl Lars Hofhansl added a comment - Ishan Chhabra In the end this an open source project. As long as there is a maintainer there'll be updates. The reasoning for retiring 0.96 is that everyone should rather go to 0.98 (you can do a rolling upgrade from 0.96 to 0.98, no data upgrade required). If we had semantic versioning going from 0.96 to 0.98 would something like going from version 2.0.x to 2.1.x (i.e. a minor version update). We're just saying: No more patches for the 2.0 code line, please upgrade to 2.1.x for bugfixes. 0.94 is the prior major version. Retiring that in favor of 0.98 would be like going from 1.0.x to 2.x.y, with no rolling upgrades, no client-server protocol compatibility, and a data upgrade step and new version of Hadoop (likely) required. So we'd be maintaining the equivalent of 1.x.y, and 2.x.y. Eventually 0.94 will be retired (i.e. nobody will contribute patches to it any more). If we want save the work maintaining 0.94 or nobody is using it anymore anyway we can retire it soon. If we want to keep maintaining it for folks who cannot risk upgrading their data we can do so too. Why are you asking? You feel we should retire 0.94 as well? Or you're worried we might retire it?
        Hide
        ishanc Ishan Chhabra added a comment -

        Lars Hofhansl, I agree with your reasoning of maintaining 0.94 a little longer (given the incompatibility and a stop the world upgrade process), but I am worried we might end up in a Python 2.x 3.x like scenario. Declaring an EOL for 0.94 might be a good way to trigger upgrades for many clients who have not done it yet and will bring more focus to the community (I see many JIRAs with won't backport for 0.94, but some patches attached, and people will keep on coming back to the mailing lists seeking help for these and other issues).

        Show
        ishanc Ishan Chhabra added a comment - Lars Hofhansl , I agree with your reasoning of maintaining 0.94 a little longer (given the incompatibility and a stop the world upgrade process), but I am worried we might end up in a Python 2.x 3.x like scenario. Declaring an EOL for 0.94 might be a good way to trigger upgrades for many clients who have not done it yet and will bring more focus to the community (I see many JIRAs with won't backport for 0.94, but some patches attached, and people will keep on coming back to the mailing lists seeking help for these and other issues).
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Is Python 2.x vs 3.x, Linux Kernel 2.x vs 3.x, Java 7 vs 8, etc, necessarily a bad thing? The older main versions exist because folks cannot (or do not want to) upgrade.

        I hear the "let's force an upgrade by unsupporting version X" from non-practicing entities a lot - i.e. those that actually do not use the product themselves. (not saying that's the case with you )

        As chance has it my organization is upgrading to 0.98 as we speak so it's not an issue for me, but I imagine if we didn't, we certainly wouldn't want to be a situation where we're on our own with a heavy investment in a certain infrastructure (in terms of H/W, operations, customer commitments, etc), and only a destructive one-way upgrade path that includes downtime. (We're doing this now before the big rollout in order to avoid these head-aches for a bit.)

        Show
        lhofhansl Lars Hofhansl added a comment - Is Python 2.x vs 3.x, Linux Kernel 2.x vs 3.x, Java 7 vs 8, etc, necessarily a bad thing? The older main versions exist because folks cannot (or do not want to) upgrade. I hear the "let's force an upgrade by unsupporting version X" from non-practicing entities a lot - i.e. those that actually do not use the product themselves. (not saying that's the case with you ) As chance has it my organization is upgrading to 0.98 as we speak so it's not an issue for me, but I imagine if we didn't, we certainly wouldn't want to be a situation where we're on our own with a heavy investment in a certain infrastructure (in terms of H/W, operations, customer commitments, etc), and only a destructive one-way upgrade path that includes downtime. (We're doing this now before the big rollout in order to avoid these head-aches for a bit.)
        Hide
        ishanc Ishan Chhabra added a comment -

        Hmm, I agree and can relate to the pain associated with a co-ordinated upgrade having gone through it myself.

        Thinking about it more, I agree a full EOL is not a good idea for 0.94, but is there are way to make its status more clearer and explicit (maybe "extended maintenance" like python 2.x) so that people running smaller clusters would consider upgrades and newer users don't use 0.94 accidentally (I see some of them doing that mostly because they start with CDH 4). It is easy for a casual observer to think that 0.94 is having active releases, whereas it is made clear in the JIRAs that new features should not be added to this branch.

        As a side note, this line should be definitely fixed in the download pages (eg. http://www.carfab.com/apachesoftware/hbase/)

        "The 0.96.x series supercedes 0.94.x. We are leaving the 'stable' pointer on the latest 0.94.x for now while 0.96 is still 'fresh'."

        Show
        ishanc Ishan Chhabra added a comment - Hmm, I agree and can relate to the pain associated with a co-ordinated upgrade having gone through it myself. Thinking about it more, I agree a full EOL is not a good idea for 0.94, but is there are way to make its status more clearer and explicit (maybe "extended maintenance" like python 2.x) so that people running smaller clusters would consider upgrades and newer users don't use 0.94 accidentally (I see some of them doing that mostly because they start with CDH 4). It is easy for a casual observer to think that 0.94 is having active releases, whereas it is made clear in the JIRAs that new features should not be added to this branch. As a side note, this line should be definitely fixed in the download pages (eg. http://www.carfab.com/apachesoftware/hbase/ ) "The 0.96.x series supercedes 0.94.x. We are leaving the 'stable' pointer on the latest 0.94.x for now while 0.96 is still 'fresh'."
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Yes. It should be a 100% that all new users should go to 0.98 (and soon 1.0, yeah!) Completely with you there.
        The stable pointer now points to 0.98. Yeah, we need to fix the text... I'll do that now.

        Show
        lhofhansl Lars Hofhansl added a comment - Yes. It should be a 100% that all new users should go to 0.98 (and soon 1.0, yeah!) Completely with you there. The stable pointer now points to 0.98. Yeah, we need to fix the text... I'll do that now.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Changed the text to this for now:
        "
        We suggest downloading the current stable release.
        The 0.98.x series is the current stable release, it supercedes 0.94.x and 0.96.x.
        "
        stack feel free to change again.

        Show
        lhofhansl Lars Hofhansl added a comment - Changed the text to this for now: " We suggest downloading the current stable release. The 0.98.x series is the current stable release, it supercedes 0.94.x and 0.96.x. " stack feel free to change again.
        Hide
        stack stack added a comment -
        Show
        stack stack added a comment - Lars Hofhansl lgtm
        Hide
        stack stack added a comment -

        Sent mail to list just now with subject: "ANN: 0.96 is being EOL'd"

        Added note to refguide (though we should start up an EOL section I'd say both what is EOL'd and how to... will wait on the how to till we've done a few).

        Updated the downloads HEADER.html to note 0.96 has been EOL'd.

        An interesting consequence of EOL that may have been plain to others but that I just realized is that now it is EOL'd, patches can go into 0.94 and 0.98 w/o having to go into 0.96.

        Show
        stack stack added a comment - Sent mail to list just now with subject: "ANN: 0.96 is being EOL'd" Added note to refguide (though we should start up an EOL section I'd say both what is EOL'd and how to... will wait on the how to till we've done a few). Updated the downloads HEADER.html to note 0.96 has been EOL'd. An interesting consequence of EOL that may have been plain to others but that I just realized is that now it is EOL'd, patches can go into 0.94 and 0.98 w/o having to go into 0.96.
        Hide
        stack stack added a comment -

        Resolving as done. If objection on mailing list or later, can reopen.

        Show
        stack stack added a comment - Resolving as done. If objection on mailing list or later, can reopen.

          People

          • Assignee:
            stack stack
            Reporter:
            stack stack
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development