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
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.
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
|
