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:[email protected]>[email protected]>
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:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of
*John Arthorne
*Sent:* Monday, September 14, 2015 7:27 AM
*To:* [email protected]
<mailto:[email protected]>
*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>https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy
[2]
<https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process>https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
john
----- Original message -----
From: Ed Merks <<mailto:[email protected]>[email protected]>
Sent by: [email protected]
<mailto:[email protected]>
To: Cross project issues
<<mailto:[email protected]>[email protected]>
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
[email protected]
<mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com |
<http://twitter.com/eclipsesource>http://twitter.com/eclipsesource
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2015.0.6125 / Virus Database: 4419/10638 - Release Date: 09/14/15
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
