Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Aleksandar Kurtakov]

- Original Message -
> From: "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com>
> To: "Cross project issues" <cross-project-issues-dev@eclipse.org>
> 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=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-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
> 
> 
> 
> 
> 

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Doug Schaefer]

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: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Kaloyan Raev <kaloya...@zend.com<mailto:kaloya...@zend.com>>
Reply-To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Date: Tuesday, September 15, 2015 at 8:57 AM
To: Cross project issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
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 
<akurt...@redhat.com<mailto:akurt...@redhat.com>> wrote:
- Original Message -
> From: "Konstantin Komissarchik" 
> <konstantin.komissarc...@oracle.com<mailto:konstantin.komissarc...@oracle.com>>
> To: "Cross project issues" 
> <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
> 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=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-boun...@eclipse.org<m

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Kaloyan Raev]

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 <dschae...@qnx.com> 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: <cross-project-issues-dev-boun...@eclipse.org> on behalf of Kaloyan
> Raev <kaloya...@zend.com>
> Reply-To: Cross project issues <cross-project-issues-dev@eclipse.org>
> Date: Tuesday, September 15, 2015 at 8:57 AM
> To: Cross project issues <cross-project-issues-dev@eclipse.org>
>
> 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 <akurt...@redhat.com>
> wrote:
>
>> - Original Message -
>> > From: "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com>
>> > To: "Cross project issues" <cross-project-issues-dev@eclipse.org>
>> > 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=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.
>>
>&g

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Stephan Herrmann]

I like the idea of 5.0 for API removal. To minimize impact on adopters:
why not schedule the jump to 5.0 for Neon+1 as to give projects a chance
to include more removal of deprecated API at once? I believe the currently
discussed API removal could easily wait until Neon+1? Then API cleanup
would be a prominent theme of that release.

Stephan

On 09/14/2015 05:13 PM, Ed Willink wrote:

Hi

Sorry Ian. See https://wiki.eclipse.org/Version_Numbering#Versioning_features

/Increment the feature's major number if any contained plug-in or feature 
increases their major number //
/
It is certainly possible for plugin major version changes to be a creeping 
disease but the feature changes with the first plugin.

If different plugins change every milestone, you maximize difficulties for 
consumers.

Much better to go for 5.x outright and we all take the hit just once.

 Regards

 Ed Willink

On 14/09/2015 16:02, Ian Bull wrote:

I may be wrong, but I don't think that updating a single bundles major version 
requires the product version number to be updated.
Eclipse currently ships with bundles numbered from 1.x (jface.databinding) to 
8.x (jetty) and we've been using 4.x as the product
version for years. I agree that we should follow our semantic version rules for 
bundles & features. Our entire base platform (OSGi
& p2) depend on this.

Does anyone have a link to how the product version relates to the bundles 
contained within the product?

Cheers,
Ian



On Mon, Sep 14, 2015 at 7:44 AM, Konstantin Komissarchik
<<mailto:konstantin.komissarc...@oracle.com>konstantin.komissarc...@oracle.com> 
wrote:

I, for one, would like to have further discussion on the topic of platform 
strictly following Semantic Versioning as it’s an
important tool in ensuring that we create valid installations that don’t 
break with class not found or method not found errors.

- Konstantin

*From:*cross-project-issues-dev-boun...@eclipse.org 
<mailto:cross-project-issues-dev-boun...@eclipse.org>
[mailto:cross-project-issues-dev-boun...@eclipse.org 
<mailto:cross-project-issues-dev-boun...@eclipse.org>] *On Behalf Of
*John Arthorne
*Sent:* Monday, September 14, 2015 7:27 AM
*To:* cross-project-issues-dev@eclipse.org 
<mailto:cross-project-issues-dev@eclipse.org>
    *Subject:* Re: [cross-project-issues-dev] Unannounced Changes Have 
Unforeseen Consequences

Hi everyone,

This has been a great discussion. I have a few points to add:

- It is very important for the Platform (and other projects) to have the 
right to occasionally remove API. In a nutshell,
maintaining API forever generally benefits existing consumers but adds pain 
and cost for those maintaining the API. As the
number of API maintainers has dwindled, the Platform made a deliberate 
choice about 5 years ago to slightly relax its previous
stringent API maintenance practices. There are APIs in Platform none of the 
remaining committers understand or use, and it
creates a large burden on them to maintain it. The huge API surface area of 
the Platform also creates a burden for new
consumers. When there are 5 available ways to do something with the 
Platform API, removing some of the oldest and least
recommended options helps new adopters chose the right path. While this 
depends on your perspective, I think moving the needle
slightly in favor of committers and new adopters is beneficial for the 
future of the Platform, even if there is some impact
for legacy code consumers.

- In this particular case, the Platform API removal process was not 
completely followed [1, 2]. The removal is being reverted
for the next Platform integration build. The API may still be removed in 
the June 2017 simultaneous release, so if you have
already taken steps to adopt the changes, consider yourself ahead of the 
game :) It is important for API removals to be widely
announced, and a justification given to the community who will be impacted 
by it. I apologize for this not being done in this
case.

- On the topic of semantic versioning, there is no easy answer. 
Incrementing the major version number of a bundle in the
Platform is guaranteed to have a massive impact on adopters, even if they 
did not use the particular API that was affected.
Nearly every annual release of the Eclipse Platform has had some very minor 
API breakage, which is always carefully documented
in the migration guide. If we strictly followed Semantic Versioning, the 
major version of much of the Platform would now be
around 12 or so by now, and adopters would have learned to completely 
remove the upper bound from their version ranges to
avoid being constantly broken at the bundle metadata level. What we have 
always done in the Platform is try to have the
version numbers reflect the anticipated overall impact on clients. In most 
release, the API is 99.9% co

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Kaloyan Raev]

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 <akurt...@redhat.com>
wrote:

> - Original Message -
> > From: "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com>
> > To: "Cross project issues" <cross-project-issues-dev@eclipse.org>
> > 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=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-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
&g

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Michael Scharf]

  
  
Indeed, breaking API without major
  version changes is an absolute
  no go. Even if only a few percent of existing plugins are
  affected, this undermines the idea of APIs and semantic
  versioning.
  
  see also https://wiki.eclipse.org/Evolving_Java-based_APIs
  
   
  
  API Prime Directive: When evolving the Component API from release to release,
do not break existing Clients.
  
      API Contract
Compatibility: API changes must not invalidate
  formerly legal Client code.
      API Usage Assumption: Every
  aspect of the API matters to some Client.
  
      API Binary
Compatibility: Pre-existing Client binaries must
  link and run with new releases of the Component without
recompiling.

  Michael
  
  On 2015-09-14 15:03, Ed Willink 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
  


  

___
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

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Konstantin Komissarchik]

I, for one, would like to have further discussion on the topic of platform 
strictly following Semantic Versioning as it’s an important tool in ensuring 
that we create valid installations that don’t break with class not found or 
method not found errors. 

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Monday, September 14, 2015 7:27 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen 
Consequences

 

Hi everyone,

 

This has been a great discussion. I have a few points to add:

 

- It is very important for the Platform (and other projects) to have the right 
to occasionally remove API. In a nutshell, maintaining API forever generally 
benefits existing consumers but adds pain and cost for those maintaining the 
API. As the number of API maintainers has dwindled, the Platform made a 
deliberate choice about 5 years ago to slightly relax its previous stringent 
API maintenance practices. There are APIs in Platform none of the remaining 
committers understand or use, and it creates a large burden on them to maintain 
it. The huge API surface area of the Platform also creates a burden for new 
consumers. When there are 5 available ways to do something with the Platform 
API, removing some of the oldest and least recommended options helps new 
adopters chose the right path. While this depends on your perspective, I think 
moving the needle slightly in favor of committers and new adopters is 
beneficial for the future of the Platform, even if there is some impact for 
legacy code consumers.

 

- In this particular case, the Platform API removal process was not completely 
followed [1, 2]. The removal is being reverted for the next Platform 
integration build. The API may still be removed in the June 2017 simultaneous 
release, so if you have already taken steps to adopt the changes, consider 
yourself ahead of the game :) It is important for API removals to be widely 
announced, and a justification given to the community who will be impacted by 
it. I apologize for this not being done in this case.

 

- On the topic of semantic versioning, there is no easy answer. Incrementing 
the major version number of a bundle in the Platform is guaranteed to have a 
massive impact on adopters, even if they did not use the particular API that 
was affected. Nearly every annual release of the Eclipse Platform has had some 
very minor API breakage, which is always carefully documented in the migration 
guide. If we strictly followed Semantic Versioning, the major version of much 
of the Platform would now be around 12 or so by now, and adopters would have 
learned to completely remove the upper bound from their version ranges to avoid 
being constantly broken at the bundle metadata level. What we have always done 
in the Platform is try to have the version numbers reflect the anticipated 
overall impact on clients. In most release, the API is 99.9% compatible and we 
don't let the rare exception dictate the overall version number. I still 
believe this approach minimizes the total impact on consumers, but if the 
community feels a stricter interpretation of SemVer is more valuable, it is 
worth discussing.

 

Links:

 

[1] https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy

[2] https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process

 

john

 

- Original message -
From: Ed Merks <ed.me...@gmail.com>
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Cross project issues <cross-project-issues-dev@eclipse.org>
Cc:
Subject: [cross-project-issues-dev] Unannounced Changes Have Unforeseen 
Consequences
Date: Sat, Sep 12, 2015 4:07 AM
  

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
 

 

 

___
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/li

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Sebastian Zarnekow]

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  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  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" > behalf of e...@willink.me.uk> wrote:
>>
>> 

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Ian Bull]

I may be wrong, but I don't think that updating a single bundles major
version requires the product version number to be updated. Eclipse
currently ships with bundles numbered from 1.x (jface.databinding) to 8.x
(jetty) and we've been using 4.x as the product version for years. I agree
that we should follow our semantic version rules for bundles & features.
Our entire base platform (OSGi & p2) depend on this.

Does anyone have a link to how the product version relates to the bundles
contained within the product?

Cheers,
Ian



On Mon, Sep 14, 2015 at 7:44 AM, Konstantin Komissarchik <
konstantin.komissarc...@oracle.com> wrote:

> I, for one, would like to have further discussion on the topic of platform
> strictly following Semantic Versioning as it’s an important tool in
> ensuring that we create valid installations that don’t break with class not
> found or method not found errors.
>
>
>
> - Konstantin
>
>
>
>
>
> *From:* cross-project-issues-dev-boun...@eclipse.org [mailto:
> cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *John Arthorne
> *Sent:* Monday, September 14, 2015 7:27 AM
> *To:* cross-project-issues-dev@eclipse.org
> *Subject:* Re: [cross-project-issues-dev] Unannounced Changes Have
> Unforeseen Consequences
>
>
>
> Hi everyone,
>
>
>
> This has been a great discussion. I have a few points to add:
>
>
>
> - It is very important for the Platform (and other projects) to have the
> right to occasionally remove API. In a nutshell, maintaining API forever
> generally benefits existing consumers but adds pain and cost for those
> maintaining the API. As the number of API maintainers has dwindled, the
> Platform made a deliberate choice about 5 years ago to slightly relax its
> previous stringent API maintenance practices. There are APIs in Platform
> none of the remaining committers understand or use, and it creates a large
> burden on them to maintain it. The huge API surface area of the Platform
> also creates a burden for new consumers. When there are 5 available ways to
> do something with the Platform API, removing some of the oldest and least
> recommended options helps new adopters chose the right path. While this
> depends on your perspective, I think moving the needle slightly in favor of
> committers and new adopters is beneficial for the future of the Platform,
> even if there is some impact for legacy code consumers.
>
>
>
> - In this particular case, the Platform API removal process was not
> completely followed [1, 2]. The removal is being reverted for the next
> Platform integration build. The API may still be removed in the June 2017
> simultaneous release, so if you have already taken steps to adopt the
> changes, consider yourself ahead of the game :) It is important for API
> removals to be widely announced, and a justification given to the community
> who will be impacted by it. I apologize for this not being done in this
> case.
>
>
>
> - On the topic of semantic versioning, there is no easy answer.
> Incrementing the major version number of a bundle in the Platform is
> guaranteed to have a massive impact on adopters, even if they did not use
> the particular API that was affected. Nearly every annual release of the
> Eclipse Platform has had some very minor API breakage, which is always
> carefully documented in the migration guide. If we strictly followed
> Semantic Versioning, the major version of much of the Platform would now be
> around 12 or so by now, and adopters would have learned to completely
> remove the upper bound from their version ranges to avoid being constantly
> broken at the bundle metadata level. What we have always done in the
> Platform is try to have the version numbers reflect the anticipated overall
> impact on clients. In most release, the API is 99.9% compatible and we
> don't let the rare exception dictate the overall version number. I still
> believe this approach minimizes the total impact on consumers, but if the
> community feels a stricter interpretation of SemVer is more valuable, it is
> worth discussing.
>
>
>
> Links:
>
>
>
> [1] https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy
>
> [2] https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
>
>
>
> john
>
>
>
> - Original message -
> From: Ed Merks <ed.me...@gmail.com>
> Sent by: cross-project-issues-dev-boun...@eclipse.org
> To: Cross project issues <cross-project-issues-dev@eclipse.org>
> Cc:
> Subject: [cross-project-issues-dev] Unannounced Changes Have Unforeseen
> Consequences
> Date: Sat, Sep 12, 2015 4:07 AM
>
>
> Hi,
>
> It was brought to my attention that
> org.eclipse.jface.viewers.TableTreeView

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Konstantin Komissarchik]

Commonly, if a feature includes a bundle or a feature whose version has 
updated, the feature’s version is updated in a similar fashion. Note that this 
doesn’t mean that versions will match, simply that an api breaking change in a 
bundle translates to an api breaking change in the feature, etc. I don’t know 
if this is formally documented somewhere.

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Ian Bull
Sent: Monday, September 14, 2015 8:03 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen 
Consequences

 

I may be wrong, but I don't think that updating a single bundles major version 
requires the product version number to be updated. Eclipse currently ships with 
bundles numbered from 1.x (jface.databinding) to 8.x (jetty) and we've been 
using 4.x as the product version for years. I agree that we should follow our 
semantic version rules for bundles & features. Our entire base platform (OSGi & 
p2) depend on this.

 

Does anyone have a link to how the product version relates to the bundles 
contained within the product?

 

Cheers,

Ian

 

 

 

On Mon, Sep 14, 2015 at 7:44 AM, Konstantin Komissarchik 
<konstantin.komissarc...@oracle.com> wrote:

I, for one, would like to have further discussion on the topic of platform 
strictly following Semantic Versioning as it’s an important tool in ensuring 
that we create valid installations that don’t break with class not found or 
method not found errors. 

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Monday, September 14, 2015 7:27 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen 
Consequences

 

Hi everyone,

 

This has been a great discussion. I have a few points to add:

 

- It is very important for the Platform (and other projects) to have the right 
to occasionally remove API. In a nutshell, maintaining API forever generally 
benefits existing consumers but adds pain and cost for those maintaining the 
API. As the number of API maintainers has dwindled, the Platform made a 
deliberate choice about 5 years ago to slightly relax its previous stringent 
API maintenance practices. There are APIs in Platform none of the remaining 
committers understand or use, and it creates a large burden on them to maintain 
it. The huge API surface area of the Platform also creates a burden for new 
consumers. When there are 5 available ways to do something with the Platform 
API, removing some of the oldest and least recommended options helps new 
adopters chose the right path. While this depends on your perspective, I think 
moving the needle slightly in favor of committers and new adopters is 
beneficial for the future of the Platform, even if there is some impact for 
legacy code consumers.

 

- In this particular case, the Platform API removal process was not completely 
followed [1, 2]. The removal is being reverted for the next Platform 
integration build. The API may still be removed in the June 2017 simultaneous 
release, so if you have already taken steps to adopt the changes, consider 
yourself ahead of the game :) It is important for API removals to be widely 
announced, and a justification given to the community who will be impacted by 
it. I apologize for this not being done in this case.

 

- On the topic of semantic versioning, there is no easy answer. Incrementing 
the major version number of a bundle in the Platform is guaranteed to have a 
massive impact on adopters, even if they did not use the particular API that 
was affected. Nearly every annual release of the Eclipse Platform has had some 
very minor API breakage, which is always carefully documented in the migration 
guide. If we strictly followed Semantic Versioning, the major version of much 
of the Platform would now be around 12 or so by now, and adopters would have 
learned to completely remove the upper bound from their version ranges to avoid 
being constantly broken at the bundle metadata level. What we have always done 
in the Platform is try to have the version numbers reflect the anticipated 
overall impact on clients. In most release, the API is 99.9% compatible and we 
don't let the rare exception dictate the overall version number. I still 
believe this approach minimizes the total impact on consumers, but if the 
community feels a stricter interpretation of SemVer is more valuable, it is 
worth discussing.

 

Links:

 

[1] https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy

[2] https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process

 

john

 

- Original message -
From: Ed Merks <ed.me...@gmail.com>
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Cross project issues <c

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Ed Willink]

Hi

Sorry Ian. See 
https://wiki.eclipse.org/Version_Numbering#Versioning_features


/Increment the feature's major number if any contained plug-in or 
feature increases their major number //

/
It is certainly possible for plugin major version changes to be a 
creeping disease but the feature changes with the first plugin.


If different plugins change every milestone, you maximize difficulties 
for consumers.


Much better to go for 5.x outright and we all take the hit just once.

Regards

Ed Willink

On 14/09/2015 16:02, Ian Bull wrote:
I may be wrong, but I don't think that updating a single bundles major 
version requires the product version number to be updated. Eclipse 
currently ships with bundles numbered from 1.x (jface.databinding) to 
8.x (jetty) and we've been using 4.x as the product version for years. 
I agree that we should follow our semantic version rules for bundles & 
features. Our entire base platform (OSGi & p2) depend on this.


Does anyone have a link to how the product version relates to the 
bundles contained within the product?


Cheers,
Ian



On Mon, Sep 14, 2015 at 7:44 AM, Konstantin Komissarchik 
<konstantin.komissarc...@oracle.com 
<mailto:konstantin.komissarc...@oracle.com>> wrote:


I, for one, would like to have further discussion on the topic of
platform strictly following Semantic Versioning as it’s an
important tool in ensuring that we create valid installations that
don’t break with class not found or method not found errors.

- Konstantin

*From:*cross-project-issues-dev-boun...@eclipse.org
<mailto:cross-project-issues-dev-boun...@eclipse.org>
[mailto:cross-project-issues-dev-boun...@eclipse.org
<mailto:cross-project-issues-dev-boun...@eclipse.org>] *On Behalf
Of *John Arthorne
*Sent:* Monday, September 14, 2015 7:27 AM
*To:* cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
    *Subject:* Re: [cross-project-issues-dev] Unannounced Changes Have
Unforeseen Consequences

Hi everyone,

This has been a great discussion. I have a few points to add:

- It is very important for the Platform (and other projects) to
have the right to occasionally remove API. In a nutshell,
maintaining API forever generally benefits existing consumers but
adds pain and cost for those maintaining the API. As the number of
API maintainers has dwindled, the Platform made a deliberate
choice about 5 years ago to slightly relax its previous stringent
API maintenance practices. There are APIs in Platform none of the
remaining committers understand or use, and it creates a large
burden on them to maintain it. The huge API surface area of the
Platform also creates a burden for new consumers. When there are 5
available ways to do something with the Platform API, removing
some of the oldest and least recommended options helps new
adopters chose the right path. While this depends on your
perspective, I think moving the needle slightly in favor of
committers and new adopters is beneficial for the future of the
Platform, even if there is some impact for legacy code consumers.

- In this particular case, the Platform API removal process was
not completely followed [1, 2]. The removal is being reverted for
the next Platform integration build. The API may still be removed
in the June 2017 simultaneous release, so if you have already
taken steps to adopt the changes, consider yourself ahead of the
game :) It is important for API removals to be widely announced,
and a justification given to the community who will be impacted by
it. I apologize for this not being done in this case.

- On the topic of semantic versioning, there is no easy answer.
Incrementing the major version number of a bundle in the Platform
is guaranteed to have a massive impact on adopters, even if they
did not use the particular API that was affected. Nearly every
annual release of the Eclipse Platform has had some very minor API
breakage, which is always carefully documented in the migration
guide. If we strictly followed Semantic Versioning, the major
version of much of the Platform would now be around 12 or so by
now, and adopters would have learned to completely remove the
upper bound from their version ranges to avoid being constantly
broken at the bundle metadata level. What we have always done in
the Platform is try to have the version numbers reflect the
anticipated overall impact on clients. In most release, the API is
99.9% compatible and we don't let the rare exception dictate the
overall version number. I still believe this approach minimizes
the total impact on consumers, but if the community feels a
stricter interpretation of SemVer is more valuable, it is worth
discussing.

Links:

[1] https:

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Ed Merks]

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 > 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"
 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
>>

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Lars Vogel]

Hi Ed W.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=475944 is about marking the
API for deletion, this would follow the normal process, of marking, waiting
two releases and afterwards (potentially) delete it.

There was a suggestion to delete it in this release, but that is no going
to happen (without PMC deciding to do so).

Best regards, Lars
Hi

TableTreeViewer removal was announced in

http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%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.isv%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

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Ian Bull]

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  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"  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

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Doug Schaefer]

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"  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

Re: [cross-project-issues-dev] Unannounced Changes Have Unforeseen Consequences

[Ed Willink]

Hi

TableTreeViewer removal was announced in

http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%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.isv%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