Doug, My goal was not to insult anyone. I just wanted to cheer up a little bit the Platform committers.
I hope you can look at this with different eyes and see another perspective. Peace, Kaloyan On Tue, Sep 15, 2015 at 6:47 PM, Doug Schaefer <[email protected]> wrote: > And an insult to all the members of the community who are working their > asses off on their own projects many of them on their own time as well, who > would love to help the platform but who also need sleep and to acquaint > themselves with their families once in a while. > > At any rate, I’m OK if the platform wants to do this. We just need to get > used to that new culture and adjust our trust in the Platform APIs. We’re > not used to builds breaking when moving to a new platform release. I > understand the reasoning and I’m sure we can get used to that, as long as > it doesn’t happen often. > > Doug. > > From: <[email protected]> on behalf of Kaloyan > Raev <[email protected]> > Reply-To: Cross project issues <[email protected]> > Date: Tuesday, September 15, 2015 at 8:57 AM > To: Cross project issues <[email protected]> > > Subject: Re: [cross-project-issues-dev] Unannounced Changes Have > Unforeseen Consequences > > Hi, > > I could not resist to share this photo. A salute to the platform > committers for keeping the platform relevant. > > > Greetings, > Kaloyan > > On Tue, Sep 15, 2015 at 9:38 AM, Aleksandar Kurtakov <[email protected]> > wrote: > >> ----- Original Message ----- >> > From: "Konstantin Komissarchik" <[email protected]> >> > To: "Cross project issues" <[email protected]> >> > 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: [email protected] >> > [mailto:[email protected]] 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 < [email protected] > 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 < [email protected] > >> 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, " [email protected] >> on >> > behalf of Ed Willink" < [email protected] on >> > >> > >> > behalf of [email protected] > 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 >> > >> [email protected] >> > >> 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 >> > > [email protected] >> > >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 >> > [email protected] >> > 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 >> > [email protected] >> > 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 >> > [email protected] >> > 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 >> > [email protected] >> > 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 >> > [email protected] >> > 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
