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:
- Adapt to real API changes.
- 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[1]
given in the Simultaneous
Release requirements
[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 <konstantin.komissarchik@xxxxxxxxxx>
To:
Brian
Payton/Santa Teresa/IBM@IBMUS, Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
10/27/2015
07:48 PM
Subject:
Re:
[cross-project-issues-dev] DTP major version bump for Neon
Sent
by: cross-project-issues-dev-bounces@xxxxxxxxxxx
![]()
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 <konstantin.komissarchik@xxxxxxxxxx>
To: Ed Merks <ed.merks@xxxxxxxxx>,
"cross-project-issues-dev@xxxxxxxxxxx"
<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
![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;cross-project-issues-dev@xxxxxxxxxxx
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: cross-project-issues-dev@xxxxxxxxxxx
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
<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.
Thanks,
- Konstantin
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
