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
<[email protected]
<mailto:[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
[2] https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process
john
----- Original message -----
From: Ed Merks <[email protected] <mailto:[email protected]>>
Sent by: [email protected]
<mailto:[email protected]>
To: Cross project issues <[email protected]
<mailto:[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
_______________________________________________
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
