If there are no breaking API changes,
the major version should not increase. Typically increasing the BREE level
is seen as "adding API" (from what ever is new in the JRE that
the BREE is increased to) but not breaking API. And, adding API is recommended
to be a 'minor' increase in version. Where Brian recommended "1.12
to 1.12.1" I would recommend
1.12 to 1.13, based on the guidelines.
Konstantin, I think the place where
your interpretation is too strict is where you say <quote> Here is my decision processâ Can you take
an Eclipse installation with the previous version of your project where
all dependencies only use your public API, update it to the new version
and have the installation continue to function. The answer in the case
of a BREE bump, is âmaybeâ, so the major version bump is required. </quote>
There is no "maybe" in this
case. Even though the BREE said 1.5, I can assure you anyone running DTP
Tools for the past several years has not been using 1.5. Even if they had
been, or, imagine instead the question was if the issue was "1.7"
to "1.8". Requiring a higher level JRE to run is not consider
"breaking". As you yourself admit, that's been done repeatedly
as new versions of Java come out.
Hence, I recommend you 'revert' the
changes you made for the major version bump. This is a hard request for
me make, so I don't make it lightly, because I know you stepped in to build
DTP, before anyone else did. And that is much appreciated, by me and many
others. But ... the change in major version will break many adapters needlessly,
since no API is breaking. And, such breakage will cause Eclipse to be viewed
less favorable by many adopters, perhaps even cause some smaller adopters
to not "move up" -- which is already a problem that Eclipse as
a whole has not dealt with well. And, we can be assured no users will be
effected, since we all assume they will be running 1.8 anyway. (Even that
change to 1.8 is questionable. Especially if headless versions of DTP Tools
are used "server side", but, I do not know that to be the case,
so I won't argue about that case. But, changing the BREE when it is not
required by the bundle's source code is definitely more aggressive than
the guidelines given in the Simultaneous
Release requirements ).
So ... please! :)
As a wordy aside, I heard 10 years ago,
from some leaders that started Eclipse (that are no longer around) that
"projects with one or two committers, are the ones most likely to
break API [or adopters]". While not strictly applicable to this case,
since you are not breaking API, I think the message is when there are only
one or two committers on a project, they should be extra careful (that
is, allow LOTS of time for review) before they make a change that would
break adopters. I think this is especially relevant to DTP precisely because
it "has not changed" in several releases, so adopters would be
especially hard-hit by such a change and this, in turn, have an indirect
negative impact on users.
I've said enough, except to thank you
again, for stepping in to build DTP quickly, when it was broken by the
Platform removing the "runtime compatibility" bundle. I certainly
do not fault you for trying to make things simpler for yourself, but in
this case, simpler for you means a lot more complicated for many others.
Teresa/IBM@IBMUS, Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
10/27/2015 07:48 PM Subject:
DTP major version bump for Neon Sent by:
The version changes have already gone in
and we are already contributing DTP v2 to Neon aggregation. Making all
the necessary updates took a non-trivial amount of my time.
I posted the version question on dtp-dev
on 10/13, but no one responded, so I proceeded with the path that makes
the most sense to me as the sole active DTP committer.
Maintaining backwards compatibility as
we undertake some sorely-needed improvements would use up contributor cycles
that DTP does not have to spare. The simultaneous release process purposefully
allows projects to ship API-breaking major releases once a year and many
projects have gone this route.
From: Brian Payton Sent: Tuesday, October 27, 2015 3:19 PM To: Cross project issues Subject: Re: [cross-project-issues-dev] DTP major version bump for
Sorry, I was away for a few days on vacation
and missed this exchange.
I agree with Ed and others that moving the BREE to Java 8 does not imply
that we need to increment the DTP major version. I think that moving
the version from 1.12 to 1.12.1 is sufficient for that.
Refactoring the features is a different issue. I agree that there
are way too many DTP features, but we should be able to deal with that
in a non-disruptive way. As far as I can tell, only a couple of the
features (the most cumulative ones) are the only ones actually used by
A move to version 2.0 would imply that DTP has significant breaking API
changes (and imply major new function) which would not be correct.
Brian Payton DTP PMC Lead Developer Tooling for Data Services IBM Silicon Valley Laboratory
Komissarchik <konstantin.komissarchik@xxxxxxxxxx> To: Ed Merks
<cross-project-issues-dev@xxxxxxxxxxx> Date: 10/24/2015
09:35 AM Subject: Re:
[cross-project-issues-dev] DTP major version bump for Neon Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
It all comes down to what you consider API. I donât take the view that
API is only Java API. I consider BREE to be part of the API, along with
other dependency specifications.
For instance, DTP 2 is further restricted to Neon. The previous version
supported a number of previous Eclipse releases by virtue of never raising
the min version in the version ranges. I am not certain how far back exactly
as it was not systematically managed in the past. The new build system
automatically calculates version ranges based on a policy and the policy
for DTP 2 is Neon+.
The bottom line is that DTP 2 is not a drop-in replacement for DTP 1.12
and the version number conveys this fact.
A bit of the backgroundâ DTP used to have a large committer and contributor
team, that over the years switched to other areas. The project has been
essentially dead for the last year or so. This went somewhat unnoticed
until the Luna version of DTP could no longer install into Neon, because
the compatibility bundle was gone, which somehow did not mean that Neon
platform should get a major version bump. Now, I am the only active (and
brand new) committer on the project. My goal is to get the project into
shape that can be more easily maintained by a much smaller team. The first
step is to get the project building at eclipse.org and to have a build
system thatâs easy for anyone to run. That part is done now. If anyone
is interested in helping out with getting DTP back on track, please send
a note to dtp-dev mailing list.
From: Ed Merks Sent: Saturday, October 24, 2015 8:31 AM To: Konstantin Komissarchik;cross-project-issues-dev@xxxxxxxxxxx Subject: Re: [cross-project-issues-dev] DTP major version bump for
Here is my decision processâ Can you take an Eclipse installation with
the previous version of your project where all dependencies only use your
public API, update it to the new version and have the installation continue
to function. The answer in the case of a BREE bump, is âmaybeâ, so the
major version bump is required. This has nothing to do with API and the version numbers is about API semantics
and binary compatibility...
I know that many projects bump BREE without a major version bump. I know of none that have done so in the past. BREE is not a basis
for such decisions.
Platform even has a complex rubric where certain level of API-breaking
changes are ok in a release without a major version bump. Projects are
choosing this path for developer convenience reason, but risk breaking
user installations in the process. They are all doing it wrong. :) Better would be to argue that an IDE shouldn't update to a bundle with
a BREE that is not satisfied by the version of Java used in that running
IDE. One could argue it's a p2 bug if such updates are allowed...
Regarding DTP 2 in particular, the BREE bump is just the first of the breaking
changes in this release. Breaking what?
The next target are the features. DTP features could use a round of consolidation
and refactoring. They are far too many of them and they donât break DTP
into components that are useful to the user. DTP breaking feature compatibility by removing features or removing bundles
from features is a different issue... Perhaps they can just introduce
new features for better grouping... Of course that makes it overall
No, a client that has compiled against your current version remains binary
compatible with your new version. No need to recompile or change
their code. They just can't run anymore unless they satisfy the highest
BREE of all their requirements. The version increment should reflect
changes in the APIs and implementations. I think a BREE change just
implies a content change which implies a micro version increment.
On 24/10/2015 11:55 AM, Kaloyan Raev wrote: Hi,
Does moving to Java 8 justify the bump of the major version? Many projects
update their BREE without updating their major version.
On Fri, Oct 23, 2015 at 12:37 PM, Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
wrote: DTP will soon contribute v2 to Neon aggregation stream. The current version
is 1.12.1. The reason for the major version bump is the move to requiring
Java 8. All DTP plugins and features will get a major version bump.
I recommend all consuming projects to prepare for this ahead of time by
relaxing the version ranges.