For any piece of software to remain relevant in the long term, it needs to evolve and that does mean making breaking changes. I don’t like the idea of the community questioning the need for every change. It’s a fallacy to weigh the cost to react against the cost to maintain as the cost to react will always be higher, which would mean that nothing can ever change in a meaningful way. The SimRel process allows projects to deliver breaking API changes once a year. I don’t see why it should be any different for the platform. Since many of us are unable to directly contribute to the platform, the least we can do is be supportive in cases like that.
Having said that, I do agree that breaking changes need to better communicated. We’ve been caught by poorly-announced platform changes in the past. I also strongly disagree with not strictly following the semantic versioning. Yes, it means less work for plugins, but it also renders everyone’s version ranges meaningless. If Neon needs to be Eclipse 5, so be it. Thanks, - Konstantin From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Sebastian Zarnekow Sent: Monday, September 14, 2015 6:24 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences 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 _______________________________________________ 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 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
