Hi, I totally second Eds and Eds remarks here. All API policies and all the bundle versioning schemes and careful changes in the past would be rendered pointless with this move. I doubt that keeping the deprecated interfaces is causing effort for the maintainers that is coming even remotely close to the pain that clients of existing, potentially broken plugins would suffer from.
I strongly recommend to weigh the benefits of removing a few lines of code from the repo against the potential harm that this will cause. If and only if the deprecated APIs get in the way of successful platform evolution, it would seem to be reasonable to discuss a major version increment along with the breakage. But even a major increment wouldn't imply that all the deprecated code should be blindly removed since deprecated doesn't mean something's not working anymore. I'm pretty sure that the backwards compatibility is a major success factor for Eclipse as a platform and we shouldn't give that away because of an intrinsic motivation to cleanup a few lines of code. Best regards, Sebastian On Mon, 14 Sep 2015 at 15:03 Ed Willink <e...@willink.me.uk> wrote: > Hi > > This discussion seems to completely ignore: > > *The major segment number must be increased when a plug-in makes breaking > changes to its API. * > > see > https://wiki.eclipse.org/Version_Numbering#When_to_change_the_major_segment > > Deprecation permits breakage but not violation of versioning. > > It is certainly very inconvenient to maintain API forever, but arbitrary > deletion without a consistent version number change is just dishonest; we > have distributed code that claims to work and it won't. > > Perhaps the solution is for the platform to have a major version increase > every two/three years allowing API clean up. Other projects will be more or > less forced to synchronize which will be a nuisance, but also a benefit, > since they too can clean up their APIs. > > Let Neon be versioned as 5.0.0 and we can all clean up. > > Regards > > Ed Willink > > > > On 14/09/2015 08:31, Ed Merks wrote: > > Ian, > > That's exactly the key issue that concerns me most. In general I've felt > uncomfortable with the version ranges for two reasons. Firstly because I > believe that once set, the lower bound is likely never carefully > reconsidered as to whether it remains valid. As such, I'm willing to bet > that a large portion, if not the the vast majority of the bundles, have > invalid lower bounds. Secondly because the upper bound is a guess; > exclusion of a major increment is the common best guess. Now it's clear to > me that even this is generally a bogus guess because any API can become > deprecated (which is not a problem), but furthermore eventually can be > removed, without the corresponding major version increment. So older EMF > bundles claiming to working with any 3.x version of Eclipse will not behave > as expected and therefore definitely they each have a bogus upper bound. > Maybe others are comfortable with all this, but personally I am not. > > EMF maintains compatibility back to Eclipse 3.6, to make reuse of the > latest version as flexible as possible for the broadest audience of clients > as possible. We build against 3.6 and generate version ranges based on > what we build against (ensuring they aren't bogus). Currently I'm working > towards EMF 2.12, i.e., 12 years of binary compatibility, and I'm > personally not comfortable removing public methods, even if they are > deprecated, while still claiming it's a 2.12 version. > > In any case, I was not aware that this was a general policy for the > platform. Perhaps I'm not the only one. I think deletions ought to be > announced, and with sufficient advanced waning... > > Regardless of how many projects are directly affected, a great many > projects are indirectly affected when EMF is affected, i.e., > notification-based updates of viewers will no longer work because of > missing class exceptions. So a good portion of Neon will simply not > function. I wonder when that would be (will be) first be noticed? > > > On 14/09/2015 6:45 AM, Ian Bull wrote: > > The reason it was not considered an API breaking change was explained to > me in [1]. > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=475833#c15 > > Cheers, > Ian > > On Sat, Sep 12, 2015 at 10:05 AM, Doug Schaefer <dschae...@qnx.com> wrote: > >> This affected CDT too. Luckily we were some what prepared and had one or >> our crack committers fix it but it did force us to make a change to >> continue on with Neon. >> >> So, I¹m not sure how this is not an API breaking change, deprecated or >> not. I believe the Platform is going to have to ask the Planning Council >> for an exception for this and get their approval. >> >> Doug. >> >> On 2015-09-12, 4:32 AM, "cross-project-issues-dev-boun...@eclipse.org on >> behalf of Ed Willink" <cross-project-issues-dev-boun...@eclipse.org on >> behalf of e...@willink.me.uk> wrote: >> >> >Hi >> > >> >TableTreeViewer removal was announced in >> > >> > >> http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.i >> >sv%2Fporting%2Fremovals.html >> > >> >But IPlatformRunnable is only announced as after June 2017 in >> > >> > >> http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.i >> >sv%2Fporting%2Fremovals.html >> > >> >so the discussed removal in >> > >> >https://bugs.eclipse.org/bugs/show_bug.cgi?id=475944 >> > >> >seems premature. >> > >> > Regards >> > >> > Ed Willink >> > >> >On 12/09/2015 09:05, Ed Merks wrote: >> >> Hi, >> >> >> >> It was brought to my attention that >> >> org.eclipse.jface.viewers.TableTreeViewer has been deleted. Yes, I >> >> know it's deprecated, but nevertheless it was once API before being >> >> deprecated so deleting it is a breaking change. I don't recall there >> >> being an announcement to begin deleting arbitrary deprecated API. >> >> >> >> In any case, I can't necessarily commit to making the necessary >> >> changes. As such I can't commit to contributing EMF Core to Neon. >> >> >> >> I would suggest reconsidering the strategy of breaking APIs and most >> >> certainly suggest any such actions ought to be announced and discussed >> >> before such actions are taken. >> >> >> >> Regards, >> >> Ed >> >> _______________________________________________ >> >> cross-project-issues-dev mailing list >> >> cross-project-issues-dev@eclipse.org >> >> To change your delivery options, retrieve your password, or >> >> unsubscribe from this list, visit >> >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> >> >> >> ----- >> >> No virus found in this message. >> >> Checked by AVG - www.avg.com >> >> Version: 2015.0.6125 / Virus Database: 4419/10626 - Release Date: >> >> 09/12/15 >> >> >> >> >> > >> >_______________________________________________ >> >cross-project-issues-dev mailing list >> >cross-project-issues-dev@eclipse.org >> >To change your delivery options, retrieve your password, or unsubscribe >> >from this list, visit >> >https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> > > > > -- > R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 > http://eclipsesource.com | <http://twitter.com/eclipsesource> > http://twitter.com/eclipsesource > > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > No virus found in this message. > Checked by AVG - www.avg.com > > Version: 2015.0.6125 / Virus Database: 4419/10637 - Release Date: 09/14/15 > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
