Konstantin,
In not sure how this plan affects the following specific bundles:
org.eclipse.datatools.connectivity.oda.design.ui
org.eclipse.datatools.connectivity.oda
org.eclipse.datatools.connectivity.oda.profile
If they increment their major version, EMF's ODA adapter support will
definitely stop working. I would need to do one of two things:
1. Adapt to real API changes.
2. Increase the upper bound because there are no breaking API changes.
Choice number 1 is justifiable as needed pain for improvements to the
API. Choice number 2 is justifiable only with the argument that you
will likely/probably/definitely break the API later in the release
cycle. If I'm currently stuck with choice 2, I can do nothing except
change the upper bound until I know what's been broken, simply waiting
until you do break it. Are there such plans to break the ODA APIs? If
at the end of the release cycle you don't break their APIs, then when
eventually in a later release when you do break them, you'll need to
increment them again, causing yet more pain for the consumers.
So a fundamental question is the following:
Do you plan *breaking API* changes to the ODA APIs? *
*If not, please balance your philosophy against the established
guidelines, i.e., please increment based on API semantics and please do
so at the point in time that it happens because that's the point in time
when the community can react.
Also, I would strongly encourage you to consider the community impact of
your philosophy. For example, I would love to make breaking changes to
EMF. As the sole active committer I can certainly argue that my
decisions take precedence, right? But I stop to consider the adverse
impact on the community, and I refrain. It's definitely a burden, so I
empathize with your plight, but if many of us make decisions focused on
lightening our own burden, the community would not function well.
Eventually our burden would be lightened by the non-existence of our
community.
Regards,
Ed
On 28/10/2015 2:39 AM, Konstantin Komissarchik wrote:
Let’s set aside the question of whether or not a BREE bump requires a
major version bump.
Simultaneous release process allows projects to contribute a major
release, with all that it implies. Many projects have done so. The
best time to bump the version is during the early milestones (now).
The DTP items that I’d like to work on for the next few months will
collectively require a major version bump, so I see no sense in
continuing to debate whether any one particular change necessitates
it. After all, we wouldn’t want to be trying to go through this in say m7.
I do not subscribe to the philosophy that projects should be averse to
making API breaking changes. Maintaining backwards compatibility is
costly both during the initial development and indefinitely in the
future as legacy code continues to confuse both contributors and
adopters. I find it better to spend the available time on a migration
guide, working with adopters (see my Dali patch) and making further
improvements.
Thanks,
- Konstantin
*From: *David M Williams
*Sent: *Tuesday, October 27, 2015 6:05 PM
*To: *Cross project issues
*Subject: *Re: [cross-project-issues-dev] DTP major version bump for Neon
I would like to comment on this issue as well.
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
<https://wiki.eclipse.org/Execution_Environments>[1] given in the
Simultaneous Release requirements
<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29>[2]).
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.
Thanks,
[1] https://wiki.eclipse.org/Execution_Environments
[2]
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29
From: Konstantin Komissarchik <[email protected]>
To: Brian Payton/Santa Teresa/IBM@IBMUS, Cross project issues
<[email protected]>,
Date: 10/27/2015 07:48 PM
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
Sent by: [email protected]
Brian,
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.
https://dev.eclipse.org/mhonarc/lists/dtp-dev/msg02320.html
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.
Thanks,
- Konstantin
*
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 Neon
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
other products.
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.
Regards,
Brian
Brian Payton
DTP PMC Lead
Developer Tooling for Data Services
IBM Silicon Valley Laboratory
From: Konstantin Komissarchik <[email protected]>
To: Ed Merks <[email protected]>,
"[email protected]"
<[email protected]>
Date: 10/24/2015 09:35 AM
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
Sent by: [email protected]
cid:_4_DD35EA30DD35E7A80005E51F85257EEC
Ed,
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.
Thanks,
- Konstantin
*
From: *Ed Merks*
Sent: *Saturday, October 24, 2015 8:31 AM*
To: *Konstantin Komissarchik;[email protected]*
Subject: *Re: [cross-project-issues-dev] DTP major version bump for Neon
Konstantin,
Comments below.
On 24/10/2015 4:46 PM, Konstantin Komissarchik wrote:
I use a strict interpretation of the versioning convention.
The version numbers is about semantics and is quite carefully
documented:
https://wiki.eclipse.org/Version_Numbering#When_to_change_the_major_segment
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 more complicated...
Thanks,
- Konstantin
*
From: *Ed Merks*
Sent: *Saturday, October 24, 2015 5:12 AM*
To: *[email protected]
<mailto:[email protected]>*
Subject: *Re: [cross-project-issues-dev] DTP major version bump for Neon
Kaloyan,
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.
Cheers,
Ed
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.
Greetings,
Kaloyan
On Fri, Oct 23, 2015 at 12:37 PM, Konstantin Komissarchik
<[email protected]
<mailto:[email protected]>> 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.
Thanks,
- Konstantin
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
