Re: [cross-project-issues-dev] DTP major version bump for Neon

["Brian Payton" <bpayton@xxxxxxxxxx>]

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

---

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