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
