This is a good approach, I think. If something is incomplete or known to be broken, and no volunteer is willing to work on it, then what choice do we have, really? Well, we can opt to do nothing and perhaps at some future time someone shows up, that is an option too, but if we want to take action without someone on hand willing to invest in a fix, the right call and action any of us probably has time to take is removal.
> On Apr 25, 2019, at 4:09 AM, Sean Busbey <bus...@apache.org> wrote: > > We're a do-acracy, which I think makes both of those things hard or > impractical. > > Someone has to be available to do releasing with a regular period for > X-month deprecation cycles to work. I doubt we can sustain e.g. something > like "you have to find a dedicated RM for 6 months of monthly minor > releases if you want to deprecate something". > > Similarly, how important a given feature is to our downstream users is > important, but it's more important how many of them are willing to show up > and do maintenance work on the feature. > > Take for example Distributed Log Replay. It was broken and either needed to > be fixed or needed to go. It doesn't matter how many folks were using it > despite our warnings about it's correctness or stability. When the call > went out, no one showed up with the time to make it work correctly so it > got yanked. > > >> On Thu, Apr 25, 2019, 00:29 Misty Linville <mi...@apache.org> wrote: >> >> For features, I think we would need to understand the popularity of a given >> feature by our user base, and that might vary wildly by feature. Do you >> think it would be possible to generalize? >> >>> On Wed, Apr 24, 2019 at 9:56 PM Stack <st...@duboce.net> wrote: >>> >>>> On Wed, Apr 24, 2019 at 9:04 PM Yu Li <car...@gmail.com> wrote: >>>> >>>> ... >>>> Thirdly, besides API deprecation, I think we should also discuss about >>> the >>>> rule for feature deprecation. We ever deprecated DLR, I could observe >>> some >>>> discussion on deprecating preemptive fast fail recently, and >> personally I >>>> think there're some more features with few usage but making code base >>>> complicated. >>>> >>>> >>> I like this suggestion. Lets start a new topic on stuff to remove. >>> >>> Thanks Yu Li, >>> S >>> >>> >>> >>> >>>> Lastly, I think we need to emphasize on adding the incompatible flag >> and >>>> release note to JIRA and updating document whenever a deprecated >>>> feature/API is removed, which IMHO is not followed quite well recently. >>>> >>>> Thanks. >>>> >>>> Best Regards, >>>> Yu >>>> >>>> >>>> On Thu, 25 Apr 2019 at 10:24, 张铎(Duo Zhang) <palomino...@gmail.com> >>> wrote: >>>> >>>>> Let's get a conclusion here? >>>>> >>>>> By default, we should try our best to keep the deprecated APIs for at >>>> least >>>>> a whole major release. All committers should have this in mind, when >>>> there >>>>> is patch which deprecates a public API, we should make sure that >> there >>> is >>>>> a @deprecated javadoc comment says on which version it is deprecated, >>> and >>>>> on which version it is expected to be removed. >>>>> >>>>> And due to the difficulties in real world, if you think the above >> rule >>>>> makes it really hard to maintain a clean and stable code base, you >> can >>>>> break the rule. But you should have a strong enough reason, and >> also, a >>>>> nice written release note, and also update the upgrading section in >> our >>>> ref >>>>> guide. >>>>> >>>>> Is this OK? >>>>> >>>>> Thanks. >>>>> >>>>> 张铎(Duo Zhang) <palomino...@gmail.com> 于2019年4月24日周三 下午2:38写道： >>>>> >>>>>> Phoenix is a good example I'd say, we have done a lot of CP related >>>>>> changes before releasing 2.0.0. But until now, Phoenix still has >>>> troubles >>>>>> to work together with 2.x, although we have already fixed several >>>>>> compatibility issues... It shows that, usually people will take >> much >>>> care >>>>>> on the alpha and beta releases... >>>>>> >>>>>> Reid Chan <reidddc...@outlook.com> 于2019年4月24日周三 上午10:58写道： >>>>>> >>>>>>> >>>>>>> As a strong coupling system to HBase, Phoenix has always been the >>>> first >>>>>>> sufferer, not only client APIs, but also some internal APIs. >>>>>>> Maybe we can ask Phoenix dev team what do they think, and get some >>>>>>> thoughts from them. >>>>>>> >>>>>>> >>>>>>> -------------------------- >>>>>>> >>>>>>> Best regards, >>>>>>> R.C >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: Sean Busbey <bus...@apache.org> >>>>>>> Sent: 24 April 2019 10:16 >>>>>>> To: dev >>>>>>> Subject: Re: [DISCUSS] Handling removal of deprecated methods and >>>>> classes >>>>>>> >>>>>>> Isn't API stabilization what we have alpha and beta releases for? >>>>>>> >>>>>>> There was nearly a year between the first alpha version of 2.0.0 >> and >>>> the >>>>>>> GA >>>>>>> release. Surely that should be a reasonable window for "trying >> out" >>> a >>>>> new >>>>>>> major release. >>>>>>> >>>>>>> I don't like the idea of telling our downstreamers that they can't >>>>>>> "really" >>>>>>> use or rely on our major releases until several minor releases in. >>>>> Either >>>>>>> we should say "API locks at X.0.0" or we should say "any API >> change >>>>> might >>>>>>> happen at a major version". >>>>>>> >>>>>>> We can always document what went away between minor releases even >> if >>>> we >>>>>>> can't give a compile time warning in advance (e.g. for the 2.0.0 >> to >>>>> 3.0.0 >>>>>>> user in your example Duo). >>>>>>> >>>>>>> We ended up trying to do that for 2.0.0 because so much had >> changed >>>> from >>>>>>> 1.0.0. >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 23, 2019, 20:51 张铎(Duo Zhang) <palomino...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>>> Ideally, we'd better keep the deprecated APIs for at least a >> whole >>>>> major >>>>>>>> version, that means user can upgrade to a new major release from >>> any >>>>>>> minor >>>>>>>> releases, without seeing the removal of any non-deprecated APIs. >>>>>>>> >>>>>>>> For example, if we deprecate a method in 2.1.0, and remove it in >>>>> 3.0.0, >>>>>>>> then the users who upgrade to 3.0.0 from 2.0.0 will see the >>> removal >>>> of >>>>>>> this >>>>>>>> method, although the method is not deprecated on 2.0.0. >>>>>>>> >>>>>>>> But considering the current status of our project(as Sean >>> mentioned >>>>>>> above), >>>>>>>> I do not think it is a good idea to fully follow the rule. One >>> more >>>>>>> thing >>>>>>>> is that, for a new major release, usually the code base is not >>>> stable >>>>>>>> enough, need to be polished. Ideally it will be stable enough >>> after >>>>> one >>>>>>> or >>>>>>>> two minor releases. This means we will introduced new APIs and >>>>>>> deprecated >>>>>>>> old APIs in these minor releases. I think this is because that >> we >>> do >>>>> not >>>>>>>> have enough test before making a new major release, but this is >> a >>>> dead >>>>>>> lock >>>>>>>> problem. If we do not publish a new major release, users will >> not >>>> try >>>>> it >>>>>>>> which means we can not get enough test, since HBase is widely >> used >>>>>>>> everywhere and the release manager can only test a small set of >>> core >>>>>>>> features... >>>>>>>> >>>>>>>> For me, I think a better way is to not follow the rule for the >>> first >>>>>>>> several releases, i.e, we are free to remove APIs in the next >>> major >>>>>>> release >>>>>>>> if they are deprecated in x.1.0 and x.2.0 releases. But once we >>>> think >>>>>>> the >>>>>>>> APIs are stable enough, we should follow the rule again, i.e, >>> newly >>>>>>>> deprecated APIs should be retained in the next major release. >> For >>>>>>> example, >>>>>>>> for 2.x release, I think the stable minor release would be 2.3.0 >>> or >>>>>>> 2.4.0, >>>>>>>> which means if the APIs you used are not deprecated in these >> minor >>>>>>> release, >>>>>>>> then you can confirm that you can still use it in the next major >>>>>>> release. >>>>>>>> But for minor releases before it, for example, 2.1.x and 2.0.x, >>>> you'd >>>>>>>> better upgrade to 2.3.0 or 2.4.0 first, as the APIs you used may >>>>>>> disappear >>>>>>>> even if they are not deprecated. >>>>>>>> >>>>>>>> And we can add the above words in the upgrading part in our ref >>>> guide. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Zach York <zyork.contribut...@gmail.com> 于2019年4月24日周三 >> 上午3:04写道： >>>>>>>> >>>>>>>>> Always good to see the history of the discussion :) It looks >>> like >>>>>>> nothing >>>>>>>>> really was decided last time (use caution if removing before a >>>> full >>>>>>> major >>>>>>>>> version), hopefully we can come up with something more >>> descriptive >>>>>>> this >>>>>>>>> time. >>>>>>>>> >>>>>>>>> I think the idea of having a tag/annotation for detailing when >>> the >>>>>>>>> method/feature is set for removal is a cool idea that we >> should >>>>>>>> investigate >>>>>>>>> further. If every deprecated method/feature had such an >>>> annotation, >>>>> it >>>>>>>>> would be easy to build automation around generating release >>>>>>>>> notes/documentation on what was removed in a particular >> version >>>>>>> (instead >>>>>>>> of >>>>>>>>> relying on someone to manually update the release note/docs). >>>>>>>>> >>>>>>>>> I agree that major releases are taking a long time to release >>> and >>>>> that >>>>>>>>> causes deprecated features to hang around for a long time, >> but I >>>>> also >>>>>>>> feel >>>>>>>>> like moving it to >= 1 minor release is a bit too quick and >>> would >>>>> add >>>>>>> to >>>>>>>>> upgrade burden. Not everyone uses every minor version so they >>>> might >>>>> be >>>>>>>>> taken unaware by the change or be less likely to upgrade as >>>> quickly. >>>>>>>>> I'm not necessarily against shortening the time. Maybe there >> is >>>> some >>>>>>> sort >>>>>>>>> of middle ground (>=2 minor releases), but that gets a little >>>> muddy >>>>>>> and >>>>>>>>> would need to be documented heavily. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Zach >>>>>>>>> >>>>>>>>> On Tue, Apr 23, 2019 at 9:37 AM Lars Francke < >>>>> lars.fran...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> We had this exact same discussion four years ago (I thought >> it >>>> was >>>>>>> last >>>>>>>>>> year :O ): < >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> https://lists.apache.org/thread.html/bbdbf135abe7d8a0a4e7e9563f0bdc3dd6b555a0d3cdc1b1fdd688c2@1427759561@%3Cdev.hbase.apache.org%3E >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Apr 23, 2019 at 6:32 PM Sean Busbey < >>> bus...@apache.org> >>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I have the same interpretation as stack. However, I think >>> the >>>>>>>>>>> expectation back when 1.0.0 was rolling out was that we'd >>>> have a >>>>>>>>>>> regular cadence of major releases to use for removing >> things >>>>> that >>>>>>> had >>>>>>>>>>> been deprecated. I don't think that cadence has actually >>>>> happened. >>>>>>>>>>> >>>>>>>>>>> For example, here's a set of major releases and how long >> it >>>> had >>>>>>> been >>>>>>>>>>> since the prior major release at the time it came out: >>>>>>>>>>> >>>>>>>>>>> * 0.94 - 4 months >>>>>>>>>>> * 0.96 - 1.5 years >>>>>>>>>>> * 0.98 - 4 months >>>>>>>>>>> * 1.0 - 1 year >>>>>>>>>>> * 2.0 - 3.25 years >>>>>>>>>>> >>>>>>>>>>> If we started a vote today 3.0 would be at 1 year. I >> suspect >>>>> it's >>>>>>>> more >>>>>>>>>>> likely to end up landing around the 2 year mark. >>>>>>>>>>> >>>>>>>>>>> Given this rate and the fact that we've made exceptions in >>> the >>>>>>> past >>>>>>>>>>> (e.g. removing things in 2.0 that were deprecated after >> 1.0 >>>> was >>>>>>>>>>> already out), should we change our behavior or change what >>> we >>>>>>>> document >>>>>>>>>>> to allow removal at a major version without such a long >> lead >>>>> time? >>>>>>>>>>> >>>>>>>>>>> On Tue, Apr 23, 2019 at 10:17 AM Jan Hentschel >>>>>>>>>>> <jan.hentsc...@ultratendency.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi everyone, >>>>>>>>>>>> >>>>>>>>>>>> in the PR for HBASE-22262< >>>>>>> https://github.com/apache/hbase/pull/162 >>>>>>>>> >>>>>>>>> we >>>>>>>>>>> noticed that there could be easily a misunderstanding on >>> when >>>> to >>>>>>>> remove >>>>>>>>>>> deprecated methods. In the book< >>>>>>>>>>> http://hbase.apache.org/book.html#hbase.versioning.post10 >>> >>> it >>>>> is >>>>>>>>>>> documented “an API needs to be deprecated for a major >>> version >>>>>>> before >>>>>>>> we >>>>>>>>>>> will change/remove it.”. As the discussion on the PR shows >>> it >>>>>>> leaves >>>>>>>>> some >>>>>>>>>>> room for interpretation and should be made more specific, >>>>>>> including >>>>>>>>> some >>>>>>>>>>> examples. I think we all agree that removing a method in >>> 3.0.0 >>>>> is >>>>>>> ok >>>>>>>>> when >>>>>>>>>>> it was deprecated back in 2.0.0, but what do we do with >>>> methods >>>>> or >>>>>>>>>> classes >>>>>>>>>>> which were deprecated in a minor or patch version? As an >>>>> example, >>>>>>> if >>>>>>>> we >>>>>>>>>>> deprecate a method in 2.3.0, should it be removed in 3.0.0 >>> or >>>>>>> 4.0.0? >>>>>>>>>>>> >>>>>>>>>>>> Best, Jan >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
