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 
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Cross project issues 
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

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 
> Sent by: cross-project-issues-dev-boun...@eclipse.org
> To: Cross project issues 
> 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 

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 
 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 
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Cross project issues 

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

Re: [cross-project-issues-dev] jetty versions - Another issue to feed on the topic of semantic versioning

[Mike Milinkovich]

Just out of curiousity, have you asked on the Jetty dev list? Since they're 
only on the release train indirectly, I'm not sure how well they monitor this 
list? 


Mike Milinkovich
mike.milinkov...@eclipse.org 
+1.613.220.3223
  Original Message  
From: Max Rydahl Andersen
Sent: Monday, September 14, 2015 10:15 PM
To: cross-project-issues-dev@eclipse.org
Reply To: Cross project issues
Subject: [cross-project-issues-dev] jetty versions - Another issue to feed on 
the topic of semantic versioning

I don't want to hijack the other thread, but it is related.

JBoss Tools noticed that Jetty has some funky API changes going
on which unless you are super careful things breaks.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=477385

basically jetty 9.2.9, 9.2.10 and 9.2.13 are not compatible with/between 
each other.

Resulting in if platform ships some parts of jetty 9.2.13 and your 
manifest says it works with 9.2.10 (jetty owns libraries says it does) 
then things fall apart since you end up with a mix of 9.2.10 and 9.2.13 
in your install and that just don't work.

Just wondering if others seen this and/or got any tips to better fix 
this going forward (besides restricting ones version range to 9.2.10 and 
nothing else)

/max
http://about.me/maxandersen
___
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] jetty versions - Another issue to feed on the topic of semantic versioning

[Alexey Kazakov]

Cross-posting the Max's question to jetty-...@eclipse.org
Thanks Mike!

On 09/14/2015 05:16 PM, Mike Milinkovich wrote:

Just out of curiousity, have you asked on the Jetty dev list? Since they're 
only on the release train indirectly, I'm not sure how well they monitor this 
list?


Mike Milinkovich
mike.milinkov...@eclipse.org
+1.613.220.3223
   Original Message
From: Max Rydahl Andersen
Sent: Monday, September 14, 2015 10:15 PM
To: cross-project-issues-dev@eclipse.org
Reply To: Cross project issues
Subject: [cross-project-issues-dev] jetty versions - Another issue to feed on 
the topic of semantic versioning

I don't want to hijack the other thread, but it is related.

JBoss Tools noticed that Jetty has some funky API changes going
on which unless you are super careful things breaks.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=477385

basically jetty 9.2.9, 9.2.10 and 9.2.13 are not compatible with/between
each other.

Resulting in if platform ships some parts of jetty 9.2.13 and your
manifest says it works with 9.2.10 (jetty owns libraries says it does)
then things fall apart since you end up with a mix of 9.2.10 and 9.2.13
in your install and that just don't work.

Just wondering if others seen this and/or got any tips to better fix
this going forward (besides restricting ones version range to 9.2.10 and
nothing else)

/max
http://about.me/maxandersen
___
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


___
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] jetty versions - Another issue to feed on the topic of semantic versioning

[Joakim Erdfelt]

We monitor this list.

However, the filed bug says "This class was API and was used by several of
the other jetty bundles."
Which is confusing, as SpinLock is internal, not API.
And using mixed versions of Jetty (on the server side) is generally frowned
upon (at least from the non-OSGi point of view).


On Mon, Sep 14, 2015 at 2:16 PM, Mike Milinkovich <
mike.milinkov...@eclipse.org> wrote:

>
> Just out of curiousity, have you asked on the Jetty dev list? Since
> they're only on the release train indirectly, I'm not sure how well they
> monitor this list?
>
>
> Mike Milinkovich
> mike.milinkov...@eclipse.org
> +1.613.220.3223
>   Original Message
> From: Max Rydahl Andersen
> Sent: Monday, September 14, 2015 10:15 PM
> To: cross-project-issues-dev@eclipse.org
> Reply To: Cross project issues
> Subject: [cross-project-issues-dev] jetty versions - Another issue to feed
> on the topic of semantic versioning
>
> I don't want to hijack the other thread, but it is related.
>
> JBoss Tools noticed that Jetty has some funky API changes going
> on which unless you are super careful things breaks.
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=477385
>
> basically jetty 9.2.9, 9.2.10 and 9.2.13 are not compatible with/between
> each other.
>
> Resulting in if platform ships some parts of jetty 9.2.13 and your
> manifest says it works with 9.2.10 (jetty owns libraries says it does)
> then things fall apart since you end up with a mix of 9.2.10 and 9.2.13
> in your install and that just don't work.
>
> Just wondering if others seen this and/or got any tips to better fix
> this going forward (besides restricting ones version range to 9.2.10 and
> nothing else)
>
> /max
> http://about.me/maxandersen
> ___
> 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
>
___
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] jetty versions - Another issue to feed on the topic of semantic versioning

[Max Rydahl Andersen]

Sorry for the misnomer, but the bundles between them self seem to have used
It as Api. 

And yes we know by heavy experience that mixed versions of Jetty is bad - even 
at the .z level. We've had the issue in past - it's just that it now repeated 
and thus we wanted to raise it to know how to handle it. 

But there is now way for us to actually control this when jetty itself in its 
version ranges says .10 when it actually needs .13 and vice Versa.

I.e. Platform required some jetty .9 or upwards at Mars.0,
We add a dependency in our plugins to other parts of jetty as .9 and upwards. 
As long as only .9 is available to Osgi to resolve things are good. 

In Mars .1 jetty .13 is bundled. Now when our bundles are resolved it ends up 
with a mix of .9 and .13 with no dependency resolution errors.  

Only at runtime the issue occurs since .9 and  .13 are actually *not* 
compatible with each other. 


/max
http://about.me/maxandersen


> On 15 Sep 2015, at 03:02, Joakim Erdfelt  wrote:
> 
> We monitor this list.
> 
> However, the filed bug says "This class was API and was used by several of 
> the other jetty bundles."
> Which is confusing, as SpinLock is internal, not API.
> And using mixed versions of Jetty (on the server side) is generally frowned 
> upon (at least from the non-OSGi point of view).
> 
> 
>> On Mon, Sep 14, 2015 at 2:16 PM, Mike Milinkovich 
>>  wrote:
>> 
>> Just out of curiousity, have you asked on the Jetty dev list? Since they're 
>> only on the release train indirectly, I'm not sure how well they monitor 
>> this list? 
>> 
>> 
>> Mike Milinkovich
>> mike.milinkov...@eclipse.org 
>> +1.613.220.3223
>>   Original Message  
>> From: Max Rydahl Andersen
>> Sent: Monday, September 14, 2015 10:15 PM
>> To: cross-project-issues-dev@eclipse.org
>> Reply To: Cross project issues
>> Subject: [cross-project-issues-dev] jetty versions - Another issue to feed 
>> on the topic of semantic versioning
>> 
>> I don't want to hijack the other thread, but it is related.
>> 
>> JBoss Tools noticed that Jetty has some funky API changes going
>> on which unless you are super careful things breaks.
>> 
>> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=477385
>> 
>> basically jetty 9.2.9, 9.2.10 and 9.2.13 are not compatible with/between
>> each other.
>> 
>> Resulting in if platform ships some parts of jetty 9.2.13 and your
>> manifest says it works with 9.2.10 (jetty owns libraries says it does)
>> then things fall apart since you end up with a mix of 9.2.10 and 9.2.13
>> in your install and that just don't work.
>> 
>> Just wondering if others seen this and/or got any tips to better fix
>> this going forward (besides restricting ones version range to 9.2.10 and
>> nothing else)
>> 
>> /max
>> http://about.me/maxandersen
>> ___
>> 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
> 
> ___
> 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] TableTreeViewer removed (please comment in bug 434575)

[Lars Vogel]

Eike,

Can you please share more details on the issues with SubProcess monitor on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=475767?

Best regards, Lars
Am 14.09.2015 7:37 vorm. schrieb "Eike Stepper" :

> Am 13.09.2015 um 18:56 schrieb David M Williams:
>
>> Thanks for letting us know of the unexpected impact, Ed. I'll talk to the
>> team, and coordinate our response.
>>
>> For a number of reasons, this may take several days, so in the mean time
>> ... are there any other projects effected by this?
>>
> I've found this issue when working with EMF Compare. Their compare/merge
> editor logs a ClassDefNotFoundError when I close it. The really bad thing
> is that the entire IDE becomes totally corrupt after this point, to the
> extent that it must be restarted. After this error I can not open *any* new
> editor, not even a simple text editor. And in some cases it seems that even
> traces of the not completely closed compare editors are kept invisibly in
> the editor area after a restart.
>
> +1 for announcing such breaking changes on cross-project-issues-dev (see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=436505#c22 , item 2)
>
> I'd also like to suggest that the @deprecated Javadoc tags be enriched
> with information about:
>
> a) when deprecation became effective, e.g., "@deprecated as of 4.5 no
> longer supported, please use Xyz instead."
>
> b) when removal is scheduled, e.g., "... Removal of Xyz is scheduled for
> 4.6."
>
>
> BTW. I would also love to see a more detailed description of how to
> replace the usage of the deprecated API in cases where more than a simple
> Find/Replace is required. A good example (for not enough infos)  is the
> recent deprecation of SubProgressMonitor. When the Problems views in my
> workspaces filled up with hundreds of deprecation warnings I followed the
> Javadoc advice "@deprecated use {@link SubMonitor} instead" and did a mass
> Find/Replace from "new SubProgressMonitor" to "SubMonitor.convert", which
> fixed all the warnings. But when I tested the resulting code it no longer
> worked correctly. Progress indicators are always either stuck at 0% or
> climb up to 100% immediately. I had to revert all my own adjustments and go
> back to a workspaces full of deprecation warnings, which, of course, is not
> a permanent solution, either...
>
> Cheers
> /Eike
>
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> You should be able to tell, other than brute force searching for the
>> family of classes, by building against our latest I-build, I20150908-0800,
>> or using it as a PDE target. If you are effected, please comment in bug
>> 434575 .
>>
>> Also, in the mean time, for those of you that "migrated" (e.g. Doug/CDT,
>> for one) can you briefly write-up what changes were needed? Or, point to
>> some Git commits that show the changes?
>> I'll confess my ignorance here, but I'm trying to determine if there is
>> an "easy pattern" to migrating, or if something that would be highly
>> variable?
>> Again, a brief comment in bug 434575 <
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=434575>would be the best
>> place to put these, so easier to find in future.
>>
>> Thanks again, and my personal apologies for the churn,
>>
>>
>>
>>
>>
>> From: Ed Merks 
>> To: Cross project issues ,
>> Date: 09/12/2015 04:06 AM
>> Subject: [cross-project-issues-dev] Unannounced Changes Have Unforeseen
>>   Consequences
>> Sent by: cross-project-issues-dev-boun...@eclipse.org
>>
>> 
>>
>>
>>
>> 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 

Re: [cross-project-issues-dev] TableTreeViewer removed (please comment in bug 434575)

[Eike Stepper]

Am 14.09.2015 um 08:27 schrieb Lars Vogel:


Eike,

Can you please share more details on the issues with SubProcess monitor on 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=475767?



Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=475767#c10

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



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