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]
*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
