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

Reply via email to