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

[Christian Campo]

Please please this discussion is starting again. Can I please ask very kindly 
that we take this discussion off cross-project. I am myself as many hundred 
others are not affect by this change but required to subscribe to cross-project.

I think it would also take out the heat of this discussion if it continues in a 
bug report in a smaller circle of people. Someone needs to open the bugzilla 
however which cannot be me, since I dont intend to follow it.

Please please open a bug

christian

Von: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of Konstantin Komissarchik 
<konstantin.komissarc...@oracle.com<mailto:konstantin.komissarc...@oracle.com>>
Antworten an: Cross issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Datum: Freitag, 30. Oktober 2015 um 07:37
An: Ed Merks <ed.me...@gmail.com<mailto:ed.me...@gmail.com>>, Cross issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] DTP major version bump for Neon


Ed,



I will not repeat the points I made earlier regarding what I consider to be a 
breaking change. I will also not engage in a debate of what constitutes 
responsible API evolution. Suffice it to say that there is more than one valid 
approach. I don’t fault you for how you are choosing to evolve EMF API. I don’t 
like being faulted for how I am choosing to evolve DTP API.



It seems like you feel that you must make a stand to try to force me to make 
this change, despite the minimal effort required on your part to uptake these 
changes. Fine. Please remove EMF ODA features from simrel aggregation so that I 
can see which project I need to engage with next.



Thanks,



- Konstantin





From: Ed Merks
Sent: Thursday, October 29, 2015 10:09 PM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


Konstantine,

You definitely get my big thumbs up for stepping up to prevent starvation! 
Unfortunately you also get my big thumbs down for the big box of sugar coated 
candies that tend to make children sick. I don't doubt at all that  your 
intentions are good.  Also, as the sole active committer on several projects, I 
can 100% empathize with your plight.  I am also sensitive to the fact that no 
good deed goes unpunished: no matter how hard one tries to do good things, 
someone will rag on it.  It's quite demoralizing so we must learn to keep the 
negaholics at bay.  You have my sympathy...

I do kindly, respectfully, and formally ask you to reconsider this disruptive 
move with DTP.Major version increments are justifiable only as they relate 
to breakage of API, which is not the case here.  As participants on the release 
train and as leaders of our development communities we should (must) carefully 
consider the impact of our actions.   In this case, your actions are needlessly 
disruptive.  They fly in the face of the documented processes, and do so over 
the objections of other community leaders.  Please, please, please reconsider...

For those who will rail about Konstantine's right to do as he believes best, 
please don't turn this into an issue about "rights".   Yes of course 
Konstantine is free to break API.  Let's not belabor that point.  I too am free 
to break API for EMF, but I also know that it's an absolute no go for my 
community, so I live with the burden imposed by the restriction and continue to 
work on the fundamentally thankless task of making sure that everything I do is 
not disruptive and therefore mostly unnoticed.  Our community must stand up for 
individual rights, but anarchy is no solution...

Note that I will not change the build for EMF ODA to build against the 
version-bumped DTP ODA bundles, so the EMF bundles will continue to exclude API 
breaking versions of DTP ODA.  It's up to the DTP project to version their 
bundles semantically to reflect true API breakage.  If anyone has a problem 
with this, I regretfully offer to withdraw the EMF ODA feature from the train.

Regards,
Ed
On 29/10/2015 5:05 PM, Erdal Karaca wrote:
I think Konstantin has adopted an orphan (that is about to starve).
By incrementing the major version Konstantin is expressing that he is going to 
invest a lot of (mental) energy to prevent the child from starvation.
@Konstantin: What do you need to keep the major version number as-is?
@Community: How else could you express your gratitude to Konstantin for what he 
is doing?

2015-10-28 19:20 GMT+01:00 Lars Vogel 
<lars.vo...@vogella.com<mailto:lars.vo...@vogella.com>>:
> So in this case Konstantin (and rest of the active DTP committers) should get 
> our full support

I agree with Alexander. Kudos from my side to Konstantin for working
on the (alm

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

[Konstantin Komissarchik]

Ed,

I will not repeat the points I made earlier regarding what I consider to be a 
breaking change. I will also not engage in a debate of what constitutes 
responsible API evolution. Suffice it to say that there is more than one valid 
approach. I don’t fault you for how you are choosing to evolve EMF API. I don’t 
like being faulted for how I am choosing to evolve DTP API.

It seems like you feel that you must make a stand to try to force me to make 
this change, despite the minimal effort required on your part to uptake these 
changes. Fine. Please remove EMF ODA features from simrel aggregation so that I 
can see which project I need to engage with next.

Thanks,

- Konstantin



From: Ed Merks
Sent: Thursday, October 29, 2015 10:09 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


Konstantine,

You definitely get my big thumbs up for stepping up to prevent starvation! 
Unfortunately you also get my big thumbs down for the big box of sugar coated 
candies that tend to make children sick. I don't doubt at all that  your 
intentions are good.  Also, as the sole active committer on several projects, I 
can 100% empathize with your plight.  I am also sensitive to the fact that no 
good deed goes unpunished: no matter how hard one tries to do good things, 
someone will rag on it.  It's quite demoralizing so we must learn to keep the 
negaholics at bay.  You have my sympathy...

I do kindly, respectfully, and formally ask you to reconsider this disruptive 
move with DTP.    Major version increments are justifiable only as they relate 
to breakage of API, which is not the case here.  As participants on the release 
train and as leaders of our development communities we should (must) carefully 
consider the impact of our actions.   In this case, your actions are needlessly 
disruptive.  They fly in the face of the documented processes, and do so over 
the objections of other community leaders.  Please, please, please reconsider...

For those who will rail about Konstantine's right to do as he believes best, 
please don't turn this into an issue about "rights".   Yes of course 
Konstantine is free to break API.  Let's not belabor that point.  I too am free 
to break API for EMF, but I also know that it's an absolute no go for my 
community, so I live with the burden imposed by the restriction and continue to 
work on the fundamentally thankless task of making sure that everything I do is 
not disruptive and therefore mostly unnoticed.  Our community must stand up for 
individual rights, but anarchy is no solution...

Note that I will not change the build for EMF ODA to build against the 
version-bumped DTP ODA bundles, so the EMF bundles will continue to exclude API 
breaking versions of DTP ODA.  It's up to the DTP project to version their 
bundles semantically to reflect true API breakage.  If anyone has a problem 
with this, I regretfully offer to withdraw the EMF ODA feature from the train.

Regards,
Ed
On 29/10/2015 5:05 PM, Erdal Karaca wrote:
I think Konstantin has adopted an orphan (that is about to starve).
By incrementing the major version Konstantin is expressing that he is going to 
invest a lot of (mental) energy to prevent the child from starvation.
@Konstantin: What do you need to keep the major version number as-is?
@Community: How else could you express your gratitude to Konstantin for what he 
is doing?

2015-10-28 19:20 GMT+01:00 Lars Vogel <lars.vo...@vogella.com>:
> So in this case Konstantin (and rest of the active DTP committers) should get 
> our full support

I agree with Alexander. Kudos from my side to Konstantin for working
on the (almost) dead DTP components.

Content-wise I also think only the minor version needs increasement
with this change but it is also more important that DTP is available
at all in Neon.

I hope Konstantin does not get discouraged by this email storm and
leaves DTP so that is returns to be a dead project.

Best regards, Lars





On Wed, Oct 28, 2015 at 3:22 PM, Aleksandar Kurtakov
<akurt...@redhat.com> wrote:
> - Original Message -
>> From: "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com>
>> To: "Ed Willink" <e...@willink.me.uk>, cross-project-issues-dev@eclipse.org
>> Sent: Wednesday, 28 October, 2015 3:44:54 PM
>> Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
>>
>>
>>
>> I gave the justification several times.
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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@eclipse.org
To change yo

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

[Erdal Karaca]

I think Konstantin has adopted an orphan (that is about to starve).
By incrementing the major version Konstantin is expressing that he is going
to invest a lot of (mental) energy to prevent the child from starvation.

@Konstantin: What do you need to keep the major version number as-is?
@Community: How else could you express your gratitude to Konstantin for
what he is doing?

2015-10-28 19:20 GMT+01:00 Lars Vogel <lars.vo...@vogella.com>:

> > So in this case Konstantin (and rest of the active DTP committers)
> should get our full support
>
> I agree with Alexander. Kudos from my side to Konstantin for working
> on the (almost) dead DTP components.
>
> Content-wise I also think only the minor version needs increasement
> with this change but it is also more important that DTP is available
> at all in Neon.
>
> I hope Konstantin does not get discouraged by this email storm and
> leaves DTP so that is returns to be a dead project.
>
> Best regards, Lars
>
>
>
>
>
> On Wed, Oct 28, 2015 at 3:22 PM, Aleksandar Kurtakov
> <akurt...@redhat.com> wrote:
> > - Original Message -
> >> From: "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com>
> >> To: "Ed Willink" <e...@willink.me.uk>,
> cross-project-issues-dev@eclipse.org
> >> Sent: Wednesday, 28 October, 2015 3:44:54 PM
> >> Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
> >>
> >>
> >>
> >> I gave the justification several times.
> >
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Ed Merks]

Konstantine,

You definitely get my big thumbs up for stepping up to prevent 
starvation! Unfortunately you also get my big thumbs down for the big 
box of sugar coated candies that tend to make children sick. I don't 
doubt at all that  your intentions are good.  Also, as the sole active 
committer on several projects, I can 100% empathize with your plight.  I 
am also sensitive to the fact that no good deed goes unpunished: no 
matter how hard one tries to do good things, someone will rag on it.  
It's quite demoralizing so we must learn to keep the negaholics at bay.  
You have my sympathy...


I do kindly, respectfully, and formally ask you to reconsider this 
disruptive move with DTP.Major version increments are justifiable 
only as they relate to breakage of API, which is not the case here.  As 
participants on the release train and as leaders of our development 
communities we should (must) carefully consider the impact of our 
actions.   In this case, your actions are needlessly disruptive.  They 
fly in the face of the documented processes, and do so over the 
objections of other community leaders.  Please, please, please reconsider...


For those who will rail about Konstantine's right to do as he believes 
best, please don't turn this into an issue about "rights".   Yes of 
course Konstantine is free to break API.  Let's not belabor that point.  
I too am free to break API for EMF, but I also know that it's an 
absolute no go for my community, so I live with the burden imposed by 
the restriction and continue to work on the fundamentally thankless task 
of making sure that everything I do is not disruptive and therefore 
mostly unnoticed.  Our community must stand up for individual rights, 
but anarchy is no solution...


Note that I will not change the build for EMF ODA to build against the 
version-bumped DTP ODA bundles, so the EMF bundles will continue to 
exclude API breaking versions of DTP ODA.  It's up to the DTP project to 
version their bundles semantically to reflect true API breakage.  If 
anyone has a problem with this, I regretfully offer to withdraw the EMF 
ODA feature from the train.


Regards,
Ed

On 29/10/2015 5:05 PM, Erdal Karaca wrote:

I think Konstantin has adopted an orphan (that is about to starve).
By incrementing the major version Konstantin is expressing that he is 
going to invest a lot of (mental) energy to prevent the child from 
starvation.


@Konstantin: What do you need to keep the major version number as-is?
@Community: How else could you express your gratitude to Konstantin 
for what he is doing?


2015-10-28 19:20 GMT+01:00 Lars Vogel <lars.vo...@vogella.com 
<mailto:lars.vo...@vogella.com>>:


> So in this case Konstantin (and rest of the active DTP committers) should 
get our full support

I agree with Alexander. Kudos from my side to Konstantin for working
on the (almost) dead DTP components.

Content-wise I also think only the minor version needs increasement
with this change but it is also more important that DTP is available
at all in Neon.

I hope Konstantin does not get discouraged by this email storm and
leaves DTP so that is returns to be a dead project.

Best regards, Lars





On Wed, Oct 28, 2015 at 3:22 PM, Aleksandar Kurtakov
<akurt...@redhat.com <mailto:akurt...@redhat.com>> wrote:
> - Original Message -
>> From: "Konstantin Komissarchik"
<konstantin.komissarc...@oracle.com
<mailto:konstantin.komissarc...@oracle.com>>
>> To: "Ed Willink" <e...@willink.me.uk <mailto:e...@willink.me.uk>>,
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
    >> Sent: Wednesday, 28 October, 2015 3:44:54 PM
>> Subject: Re: [cross-project-issues-dev] DTP major version bump
for Neon
>>
>>
>>
>> I gave the justification several times.
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
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@eclipse.org
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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Ed Willink]

On 28/10/2015 13:13, Konstantin Komissarchik wrote:


I have no specific plans re ODA’s Java API.


So absolutely no justification for a change then. There is no need for 
all plugins to bump together. It is cosmetically nice to see all plugins 
with the same version, but it just isn't tenable long term.


For instance many OCL plugins remain at 3.x although those that have 
been affected by UML major changes have moved to 4.x and 5.x.


Inflicting a major change on clients is not a bit of a pain, it is a 
major pain, particularly for those clients that are stable and 
consequently have minimal maintenance teams. In some cases useful but 
unmaintained tools, such as UML2 Tools, are killed by the major version 
change.


Regards

Ed Willink
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Daniel Megert]

> Inflicting a major change on clients is not a bit of a pain, it is a 
major pain, particularly for those clients that are stable and 
consequently have minimal maintenance teams.
> In some cases useful but unmaintained tools, such as UML2 Tools, are 
killed by the major version change.

+1

Dani



From:   Ed Willink <e...@willink.me.uk>
To: cross-project-issues-dev@eclipse.org
Date:   28.10.2015 14:29
Subject:    Re: [cross-project-issues-dev] DTP major version bump for 
Neon
Sent by:cross-project-issues-dev-boun...@eclipse.org




On 28/10/2015 13:13, Konstantin Komissarchik wrote:

 
I have no specific plans re ODA?s Java API.
 

So absolutely no justification for a change then. There is no need for all 
plugins to bump together. It is cosmetically nice to see all plugins with 
the same version, but it just isn't tenable long term.

For instance many OCL plugins remain at 3.x although those that have been 
affected by UML major changes have moved to 4.x and 5.x.

Inflicting a major change on clients is not a bit of a pain, it is a major 
pain, particularly for those clients that are stable and consequently have 
minimal maintenance teams. In some cases useful but unmaintained tools, 
such as UML2 Tools, are killed by the major version change.

Regards

Ed Willink___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Konstantin Komissarchik]

All DTP bundles received a major version bump, including the three that you’ve 
listed. As I’ve already explained, I consider the BREE bump to Java 8 a 
breaking API change on it’s own and all bundles received this change. Another 
likely-breaking change is that all DTP bundles now receive automatic 
calculation of required version ranges for outgoing dependencies based on Neon 
as the min-bound.

I see that WTP has contributed a build that adapts to these changes and EMF is 
next in line. Since EMF also uses automatic version range calculation, you 
should get the correct ranges once you build with DTP 2. Consider this as 
needed pain, if you must. It’s certainly the least that projects that benefit 
from DTP can do to help out.

https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.VALIDATE/133/console

I have no specific plans re ODA’s Java API.

- Konstantin




From: Ed Merks
Sent: Tuesday, October 27, 2015 11:50 PM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


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:
1. Adapt to real API changes.
2. 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 

Here is my decision process… Can you take an Eclipse installation with the 
previous version of yo

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

[Konstantin Komissarchik]

I gave the justification several times. You are choosing to disregard it. Java 
API is not bundle’s sole API. I don’t consider a restriction in requirements a 
compatible change. DTP 2 is certainly not a drop-in replacement for DTP 1.12 
and the version numbering truthfully communicates that fact. 

I understand the temptation to fudge the truth when it comes to version 
numbers, but that doesn’t make it a sound engineering practice.

- Konstantin



From: Ed Willink
Sent: Wednesday, October 28, 2015 6:29 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon



On 28/10/2015 13:13, Konstantin Komissarchik wrote:

 
I have no specific plans re ODA’s Java API.
 

So absolutely no justification for a change then. There is no need for all 
plugins to bump together. It is cosmetically nice to see all plugins with the 
same version, but it just isn't tenable long term.

For instance many OCL plugins remain at 3.x although those that have been 
affected by UML major changes have moved to 4.x and 5.x.

Inflicting a major change on clients is not a bit of a pain, it is a major 
pain, particularly for those clients that are stable and consequently have 
minimal maintenance teams. In some cases useful but unmaintained tools, such as 
UML2 Tools, are killed by the major version change.

    Regards

        Ed Willink


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Christian Campo]

+1

Am 28.10.15, 15:22 schrieb "cross-project-issues-dev-boun...@eclipse.org
on behalf of Aleksandar Kurtakov" unter
<cross-project-issues-dev-boun...@eclipse.org on behalf of
akurt...@redhat.com>:

>- Original Message -
>> From: "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com>
>> To: "Ed Willink" <e...@willink.me.uk>,
>>cross-project-issues-dev@eclipse.org
>> Sent: Wednesday, 28 October, 2015 3:44:54 PM
>> Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
>>
>>
>>
>> I gave the justification several times.
>
>If nothing else we as a community have to learn to respect the opinion of
>the one doing the job especially in cases like this when someone revives
>an almost dead project and try not to enforce our view of the world on
>him/her. So in this case Konstantin (and rest of the active DTP
>committers) should get our full support instead of arguing like this -
>both sides have their views with reasoning behind it so chances to
>convince are close to zero. Given that Konstantin jumped in and done the
>work so we can get DTP back in Neon his reasoning is way more sound to me
>:).
>
>Alexander Kurtakov
>Red Hat Eclipse team
>
>> You are choosing to disregard it.
>> Java API is not bundle¹s sole API. I don¹t consider a restriction in
>> requirements a compatible change. DTP 2 is certainly not a drop-in
>> replacement for DTP 1.12 and the version numbering truthfully
>>communicates
>> that fact.
>>
>>
>>
>> I understand the temptation to fudge the truth when it comes to version
>> numbers, but that doesn¹t make it a sound engineering practice.
>>
>>
>>
>> - Konstantin
>>
>>
>>
>>
>>
>>
>>
>> From: Ed Willink
>> Sent: Wednesday, October 28, 2015 6:29 AM
>> To: cross-project-issues-dev@eclipse.org
>> Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 28/10/2015 13:13, Konstantin Komissarchik wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>> I have no specific plans re ODA¹s Java API.
>>
>>
>>
>>
>>
>> So absolutely no justification for a change then. There is no need for
>>all
>> plugins to bump together. It is cosmetically nice to see all plugins
>>with
>> the same version, but it just isn't tenable long term.
>>
>> For instance many OCL plugins remain at 3.x although those that have
>>been
>> affected by UML major changes have moved to 4.x and 5.x.
>>
>> Inflicting a major change on clients is not a bit of a pain, it is a
>>major
>> pain, particularly for those clients that are stable and consequently
>>have
>> minimal maintenance teams. In some cases useful but unmaintained tools,
>>such
>> as UML2 Tools, are killed by the major version change.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>>
>>
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> 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@eclipse.org
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Konstantin Komissarchik]

> potentially no impact on most consumers of your API 

And here lies the crux of our disagreement. I take an absolute position on this 
issue. Potentially not breaking a consumer with an existing DTP installation is 
not the same as not breaking them. Any other position throws into question why 
we even bother having a versioning convention. By definition, any API change 
can be characterized as potentially having no impact.

- Konstantin



From: John Arthorne
Sent: Wednesday, October 28, 2015 8:07 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon


> I understand the temptation to fudge the truth when it comes to version 
>numbers, but that doesn’t make it a sound engineering practice.
 
You appear to be the first person to claim that making version numbers reflect 
changes to runtime dependencies is sound engineering practice. Even Java itself 
did not update its major version with Java 8 (which is officially version 1.8 
at the JVM level). Changes to your dependencies have no direct impact on your 
API, and potentially no impact on most consumers of your API. A consumer of 
your bundle may already have a dependency on Java 8 (or whatever the case may 
be), and therefore could not possibly be impacted by your change. By updating 
your BREE, you have ensured that your bundle will not even be loaded by OSGi in 
a runtime using Java 7 or earlier, which is already a strong enough hint to any 
consumer impacted by this change. Updating the bundle version number as well 
offers absolutely no benefit.
 
I will agree with Alex, that as the person doing the work you have the right to 
make these changes, however unjustified. The consumer community will have to 
react accordingly (by updating manifests, contributing to the project, removing 
the dependency, forking, etc).
 
John
 
- Original message -
From: Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Ed Willink <e...@willink.me.uk>, "cross-project-issues-dev@eclipse.org" 
<cross-project-issues-dev@eclipse.org>
Cc:
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
Date: Wed, Oct 28, 2015 9:45 AM
 
I gave the justification several times. You are choosing to disregard it. Java 
API is not bundle’s sole API. I don’t consider a restriction in requirements a 
compatible change. DTP 2 is certainly not a drop-in replacement for DTP 1.12 
and the version numbering truthfully communicates that fact.
 
I understand the temptation to fudge the truth when it comes to version 
numbers, but that doesn’t make it a sound engineering practice.
 
- Konstantin
 
 

From: Ed Willink
Sent: Wednesday, October 28, 2015 6:29 AM
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
 
On 28/10/2015 13:13, Konstantin Komissarchik wrote:
 
 
I have no specific plans re ODA’s Java API.
 
 
So absolutely no justification for a change then. There is no need for all 
plugins to bump together. It is cosmetically nice to see all plugins with the 
same version, but it just isn't tenable long term.

For instance many OCL plugins remain at 3.x although those that have been 
affected by UML major changes have moved to 4.x and 5.x.

Inflicting a major change on clients is not a bit of a pain, it is a major 
pain, particularly for those clients that are stable and consequently have 
minimal maintenance teams. In some cases useful but unmaintained tools, such as 
UML2 Tools, are killed by the major version change.

    Regards

        Ed Willink
 
 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Ed Willink]

Hi

Perhaps you can just follow the community experience.

You don't have to change your BREE at all, but you will still impose a 
Java 8 BREE on your Neon customers, since the platform already has a Job 
component that requires Java 8. I am not aware of anyone suggesting that 
this BREE change requires the platform move to e5.


I also write from direct experience. When I took over OCL, I found that 
UML was taking a major version change requiring an OCL move from version 
2.x to 3.x. I mistakenly thought that the previous failure of other 
plugins to move from 1.x to 2.x was a historical mistake, so I corrected 
it. Everything became nice and simple; 3.x all round. Except that client 
builds broke. With the benefit of experience I now know that the 1.x 
plugins could still be 1.x many years later and I need never have 
inflicted the pain on my clients. (Belated apologies to them.)


Regards

Ed Willink

On 28/10/2015 15:24, Konstantin Komissarchik wrote:


> potentially no impact on most consumers of your API

And here lies the crux of our disagreement. I take an absolute 
position on this issue. Potentially not breaking a consumer with an 
existing DTP installation is not the same as not breaking them. Any 
other position throws into question why we even bother having a 
versioning convention. By definition, any API change can be 
characterized as potentially having no impact.


- Konstantin


*From: *John Arthorne
*Sent: *Wednesday, October 28, 2015 8:07 AM
*To: *cross-project-issues-dev@eclipse.org
*Subject: *Re: [cross-project-issues-dev] DTP major version bump for Neon

> I understand the temptation to fudge the truth when it comes to version 
numbers, but that doesn’t make it a sound engineering practice.


You appear to be the first person to claim that making version numbers 
reflect changes to runtime dependencies is sound engineering 
practice. Even Java itself did not update its major version with Java 
8 (which is officially version 1.8 at the JVM level). Changes to your 
dependencies have no direct impact on your API, and potentially no 
impact on most consumers of your API. A consumer of your bundle may 
already have a dependency on Java 8 (or whatever the case may be), and 
therefore could not possibly be impacted by your change. By updating 
your BREE, you have ensured that your bundle will not even be loaded 
by OSGi in a runtime using Java 7 or earlier, which is already a 
strong enough hint to any consumer impacted by this change. Updating 
the bundle version number as well offers absolutely no benefit.


I will agree with Alex, that as the person doing the work you have the 
right to make these changes, however unjustified. The consumer 
community will have to react accordingly (by updating manifests, 
contributing to the project, removing the dependency, forking, etc).


John

- Original message -
From: Konstantin Komissarchik <konstantin.komissarc...@oracle.com>
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Ed Willink <e...@willink.me.uk>,
"cross-project-issues-dev@eclipse.org"
<cross-project-issues-dev@eclipse.org>
Cc:
Subject: Re: [cross-project-issues-dev] DTP major version bump for
Neon
Date: Wed, Oct 28, 2015 9:45 AM

I gave the justification several times. You are choosing to
disregard it. Java API is not bundle’s sole API. I don’t consider
a restriction in requirements a compatible change. DTP 2 is
certainly not a drop-in replacement for DTP 1.12 and the version
numbering truthfully communicates that fact.

I understand the temptation to fudge the truth when it comes to
version numbers, but that doesn’t make it a sound engineering
practice.

- Konstantin


*From: *Ed Willink
*Sent: *Wednesday, October 28, 2015 6:29 AM
*To: *cross-project-issues-dev@eclipse.org
*Subject: *Re: [cross-project-issues-dev] DTP major version bump
for Neon

On 28/10/2015 13:13, Konstantin Komissarchik wrote:

I have no specific plans re ODA’s Java API.

So absolutely no justification for a change then. There is no need
for all plugins to bump together. It is cosmetically nice to see
all plugins with the same version, but it just isn't tenable long
term.

For instance many OCL plugins remain at 3.x although those that
have been affected by UML major changes have moved to 4.x and 5.x.

Inflicting a major change on clients is not a bit of a pain, it is
a major pain, particularly for those clients that are stable and
consequently have minimal maintenance teams. In some cases useful
but unmaintained tools, such as UML2 Tools, are killed by the
major version change.

Regards

Ed Willink

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your

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

[Aleksandar Kurtakov]

- Original Message -
> From: "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com>
> To: "Ed Willink" <e...@willink.me.uk>, cross-project-issues-dev@eclipse.org
> Sent: Wednesday, 28 October, 2015 3:44:54 PM
> Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
> 
> 
> 
> I gave the justification several times. 

If nothing else we as a community have to learn to respect the opinion of the 
one doing the job especially in cases like this when someone revives an almost 
dead project and try not to enforce our view of the world on him/her. So in 
this case Konstantin (and rest of the active DTP committers) should get our 
full support instead of arguing like this - both sides have their views with 
reasoning behind it so chances to convince are close to zero. Given that 
Konstantin jumped in and done the work so we can get DTP back in Neon his 
reasoning is way more sound to me :).

Alexander Kurtakov
Red Hat Eclipse team

> You are choosing to disregard it.
> Java API is not bundle’s sole API. I don’t consider a restriction in
> requirements a compatible change. DTP 2 is certainly not a drop-in
> replacement for DTP 1.12 and the version numbering truthfully communicates
> that fact.
> 
> 
> 
> I understand the temptation to fudge the truth when it comes to version
> numbers, but that doesn’t make it a sound engineering practice.
> 
> 
> 
> - Konstantin
> 
> 
> 
> 
> 
> 
> 
> From: Ed Willink
> Sent: Wednesday, October 28, 2015 6:29 AM
> To: cross-project-issues-dev@eclipse.org
> Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 28/10/2015 13:13, Konstantin Komissarchik wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> I have no specific plans re ODA’s Java API.
> 
> 
> 
> 
> 
> So absolutely no justification for a change then. There is no need for all
> plugins to bump together. It is cosmetically nice to see all plugins with
> the same version, but it just isn't tenable long term.
> 
> For instance many OCL plugins remain at 3.x although those that have been
> affected by UML major changes have moved to 4.x and 5.x.
> 
> Inflicting a major change on clients is not a bit of a pain, it is a major
> pain, particularly for those clients that are stable and consequently have
> minimal maintenance teams. In some cases useful but unmaintained tools, such
> as UML2 Tools, are killed by the major version change.
> 
> Regards
> 
> Ed Willink
> 
> 
> 
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Ed Merks]

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:


1. Adapt to real API changes.
2. 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


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.



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 

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

[Christian Campo]

Can we take this discussion into a bugreport and remove it from crossproject 
and then everyone interested in seeing you hitting Konstantin can subscribe….

christian

Von: 
<cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>>
 on behalf of John Arthorne 
<john_artho...@ca.ibm.com<mailto:john_artho...@ca.ibm.com>>
Antworten an: Cross issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Datum: Mittwoch, 28. Oktober 2015 um 16:54
An: Cross issues 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] DTP major version bump for Neon

>And here lies the crux of our disagreement. I take an absolute position on 
>this issue. Potentially not breaking a >consumer with an existing DTP 
>installation is not the same as not breaking them. Any other position throws 
>into >question why we even bother having a versioning convention. By 
>definition, any API change can be >characterized as potentially having no 
>impact.

Yes, your approach does guarantee a breaking change for all clients, whereas 
updating the BREE only impacts consumers that are actually affected by the 
change. Congratulations on achieving consistency on that :)

John


- Original message -
From: Konstantin Komissarchik 
<konstantin.komissarc...@oracle.com<mailto:konstantin.komissarc...@oracle.com>>
To: John Arthorne/Ottawa/IBM@IBMCA, 
"cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>"
 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Cc:
Subject: RE: [cross-project-issues-dev] DTP major version bump for Neon
Date: Wed, Oct 28, 2015 11:24 AM


> potentially no impact on most consumers of your API



And here lies the crux of our disagreement. I take an absolute position on this 
issue. Potentially not breaking a consumer with an existing DTP installation is 
not the same as not breaking them. Any other position throws into question why 
we even bother having a versioning convention. By definition, any API change 
can be characterized as potentially having no impact.



- Konstantin





From: John Arthorne
Sent: Wednesday, October 28, 2015 8:07 AM
To: 
cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon





> I understand the temptation to fudge the truth when it comes to version 
> numbers, but that doesn’t make it a sound engineering practice.



You appear to be the first person to claim that making version numbers reflect 
changes to runtime dependencies is sound engineering practice. Even Java itself 
did not update its major version with Java 8 (which is officially version 1.8 
at the JVM level). Changes to your dependencies have no direct impact on your 
API, and potentially no impact on most consumers of your API. A consumer of 
your bundle may already have a dependency on Java 8 (or whatever the case may 
be), and therefore could not possibly be impacted by your change. By updating 
your BREE, you have ensured that your bundle will not even be loaded by OSGi in 
a runtime using Java 7 or earlier, which is already a strong enough hint to any 
consumer impacted by this change. Updating the bundle version number as well 
offers absolutely no benefit.



I will agree with Alex, that as the person doing the work you have the right to 
make these changes, however unjustified. The consumer community will have to 
react accordingly (by updating manifests, contributing to the project, removing 
the dependency, forking, etc).



John



- Original message -
From: Konstantin Komissarchik 
<konstantin.komissarc...@oracle.com<mailto:konstantin.komissarc...@oracle.com>>
Sent by: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
To: Ed Willink <e...@willink.me.uk<mailto:e...@willink.me.uk>>, 
"cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>"
 
<cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>>
Cc:
Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
Date: Wed, Oct 28, 2015 9:45 AM


I gave the justification several times. You are choosing to disregard it. Java 
API is not bundle’s sole API. I don’t consider a restriction in requirements a 
compatible change. DTP 2 is certainly not a drop-in replacement for DTP 1.12 
and the version numbering truthfully communicates that fact.



I understand the temptation to fudge the truth when it comes to version 
numbers, but that doesn’t make it a sound engineering practice.



- Konstantin





From: Ed Willink
Sent: Wednesday, October 28, 2015 6:29 AM
To: 
cros

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

[John Arthorne]

>And here lies the crux of our disagreement. I take an absolute position on this issue. Potentially not breaking a >consumer with an existing DTP installation is not the same as not breaking them. Any other position throws into >question why we even bother having a versioning convention. By definition, any API change can be >characterized as potentially having no impact.
 
Yes, your approach does guarantee a breaking change for all clients, whereas updating the BREE only impacts consumers that are actually affected by the change. Congratulations on achieving consistency on that :)
 
John
 
 
- Original message -From: Konstantin Komissarchik <konstantin.komissarc...@oracle.com>To: John Arthorne/Ottawa/IBM@IBMCA, "cross-project-issues-dev@eclipse.org" <cross-project-issues-dev@eclipse.org>Cc:Subject: RE: [cross-project-issues-dev] DTP major version bump for NeonDate: Wed, Oct 28, 2015 11:24 AM 
> potentially no impact on most consumers of your API
 
And here lies the crux of our disagreement. I take an absolute position on this issue. Potentially not breaking a consumer with an existing DTP installation is not the same as not breaking them. Any other position throws into question why we even bother having a versioning convention. By definition, any API change can be characterized as potentially having no impact.
 
- Konstantin
 
 
From: John ArthorneSent: Wednesday, October 28, 2015 8:07 AMTo: cross-project-issues-dev@eclipse.orgSubject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
> I understand the temptation to fudge the truth when it comes to version numbers, but that doesn’t make it a sound engineering practice.
 
You appear to be the first person to claim that making version numbers reflect changes to runtime dependencies is sound engineering practice. Even Java itself did not update its major version with Java 8 (which is officially version 1.8 at the JVM level). Changes to your dependencies have no direct impact on your API, and potentially no impact on most consumers of your API. A consumer of your bundle may already have a dependency on Java 8 (or whatever the case may be), and therefore could not possibly be impacted by your change. By updating your BREE, you have ensured that your bundle will not even be loaded by OSGi in a runtime using Java 7 or earlier, which is already a strong enough hint to any consumer impacted by this change. Updating the bundle version number as well offers absolutely no benefit.
 
I will agree with Alex, that as the person doing the work you have the right to make these changes, however unjustified. The consumer community will have to react accordingly (by updating manifests, contributing to the project, removing the dependency, forking, etc).
 
John
 
- Original message -From: Konstantin Komissarchik <konstantin.komissarc...@oracle.com>Sent by: cross-project-issues-dev-boun...@eclipse.orgTo: Ed Willink <e...@willink.me.uk>, "cross-project-issues-dev@eclipse.org" <cross-project-issues-dev@eclipse.org>Cc:Subject: Re: [cross-project-issues-dev] DTP major version bump for NeonDate: Wed, Oct 28, 2015 9:45 AM 
I gave the justification several times. You are choosing to disregard it. Java API is not bundle’s sole API. I don’t consider a restriction in requirements a compatible change. DTP 2 is certainly not a drop-in replacement for DTP 1.12 and the version numbering truthfully communicates that fact.
 
I understand the temptation to fudge the truth when it comes to version numbers, but that doesn’t make it a sound engineering practice.
 
- Konstantin
 
 
From: Ed WillinkSent: Wednesday, October 28, 2015 6:29 AMTo: cross-project-issues-dev@eclipse.orgSubject: Re: [cross-project-issues-dev] DTP major version bump for Neon
 
 
 
On 28/10/2015 13:13, Konstantin Komissarchik wrote:
 
 
I have no specific plans re ODA’s Java API.
 
 
So absolutely no justification for a change then. There is no need for all plugins to bump together. It is cosmetically nice to see all plugins with the same version, but it just isn't tenable long term.For instance many OCL plugins remain at 3.x although those that have been affected by UML major changes have moved to 4.x and 5.x.Inflicting a major change on clients is not a bit of a pain, it is a major pain, particularly for those clients that are stable and consequently have minimal maintenance teams. In some cases useful but unmaintained tools, such as UML2 Tools, are killed by the major version change.    Regards        Ed Willink
 
 
___cross-project-issues-dev mailing listcross-project-issues-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 
 
 
 
 

___
cross-project-issues-dev mailing list
cross-project-issues-dev

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

[Lars Vogel]

> So in this case Konstantin (and rest of the active DTP committers) should get 
> our full support

I agree with Alexander. Kudos from my side to Konstantin for working
on the (almost) dead DTP components.

Content-wise I also think only the minor version needs increasement
with this change but it is also more important that DTP is available
at all in Neon.

I hope Konstantin does not get discouraged by this email storm and
leaves DTP so that is returns to be a dead project.

Best regards, Lars





On Wed, Oct 28, 2015 at 3:22 PM, Aleksandar Kurtakov
<akurt...@redhat.com> wrote:
> - Original Message -
>> From: "Konstantin Komissarchik" <konstantin.komissarc...@oracle.com>
>> To: "Ed Willink" <e...@willink.me.uk>, cross-project-issues-dev@eclipse.org
>> Sent: Wednesday, 28 October, 2015 3:44:54 PM
>> Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
>>
>>
>>
>> I gave the justification several times.
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Brian Payton]

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.komissarc...@oracle.com>
To: Ed Merks <ed.me...@gmail.com>, 
"cross-project-issues-dev@eclipse.org" 
<cross-project-issues-dev@eclipse.org>
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-boun...@eclipse.org



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@eclipse.org
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: Saturd

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

[Konstantin Komissarchik]

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.komissarc...@oracle.com>
To:        Ed Merks <ed.me...@gmail.com>, 
"cross-project-issues-dev@eclipse.org" <cross-project-issues-dev@eclipse.org>
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-boun...@eclipse.org




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@eclipse.org
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

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

[Konstantin Komissarchik]

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 

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.


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.komissarc...@oracle.com>
To:        Brian Payton/Santa Teres

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

[David M Williams]

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 

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.


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.komissarc...@oracle.com>
To: Brian Payton/Santa Teresa/IBM@IBMUS, Cross project issues 
<cross-project-issues-dev@eclipse.org>, 
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-boun...@eclipse.org



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 day

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

[Konstantin Komissarchik]

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@eclipse.org
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@eclipse.org
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.komissarc...@oracle.com> 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 

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

[Ed Merks]

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 
> 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@eclipse.org

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@eclipse.org
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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Kaloyan Raev]

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.komissarc...@oracle.com> 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@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Konstantin Komissarchik]

The initial DTP 2 contribution is now in. The first affected project is WTP’s 
Dali/JPA. 

https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.VALIDATE/131/console

I have created a bug and attached a patch.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=480552

Thanks,

- Konstantin



From: Konstantin Komissarchik
Sent: Friday, October 23, 2015 1:02 PM
To: Cross project issues
Subject: [cross-project-issues-dev] DTP major version bump for Neon


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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev