| Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences |
----- Original Message -----
> From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
> Sent: Monday, 14 September, 2015 5:25:46 PM
> Subject: Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences
>
>
>
> 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.
Thanks for saying it. On platform side it's a really tough decision which most of the time is like "should I fix halves of two bugs or do one entirely". Maintaining and adding new things while keeping 100% API compatibility costs 2-5 times more for the regular cases (my SWT hat on). The community as a whole have to realize that there aren't many options - either maintenance burden is shared with way more people(volunteers are more than welcome) to allow development too so platform doesn't ruin under its own weight (in short more shoulders needed) or deprecated stuff gets removed and another gets deprecated to the amount that current maintainers can carry. The choice for which path to take is not to be done by the current committers it is something that the community will decide by doing(or not) something.
>
>
>
> Having said that, I do agree that breaking changes need to better
> communicated.
At platform side there is a detailed migration guide done with every release (e.g. http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/porting/removals.html?cp=2_3_0 and http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fporting%2Fremovals.html&cp=2_3_0 and so on). If this is not good enough (I considered this as the minimum consumers have to read deeply) let us know how to improve it but again please consider the cost of doing certain actions.
> 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.
I see the both sides of the problem and there is no silver bullet. Another thing is Eclipse version being coupled with semver of plugins which doesn't make much sense to me. If there is API breaking change in a bundle it doesn't mean that this justifies bumping Eclipse (platform) version. What about bringing it to next Architecture council for faster discussion and hopefully coming with a decision?
Alexander Kurtakov
Red Hat Eclipse team
>
>
>
> Thanks,
>
>
>
> - Konstantin
>
>
>
>
>
>
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] 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 < ed@xxxxxxxxxxxxx > 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 < dschaefer@xxxxxxx > 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-bounces@xxxxxxxxxxx on
> behalf of Ed Willink" < cross-project-issues-dev-bounces@xxxxxxxxxxx on
>
>
> behalf of ed@xxxxxxxxxxxxx > 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@xxxxxxxxxxx
> >> 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@xxxxxxxxxxx
> >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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Attachment:
platform-committer.jpg
Description: JPEG image
