Re: [cross-project-issues-dev] Problems with Simrel contributionre: org.eclipse.e4.ui.model.workbench

2017-03-13 Thread Ed Willink 

Hi

Pedantically, adding and exploiting @noimplement requires a major 
version change anyway, but if we did that for every "oops, that should 
not have been API" we would always need major version changes.


Practically, I find that the improved API checking for name addition in 
M6 makes non-major-change evolution very very hard. For OCL, which has 
been fairly stable moving to 6.3.0, I found that I needed some API 
filters that I could not really justify for 'mad bad users'. I think we 
need a new policy to express the boundary between irresponsible 
extension code and irresponsible extensions to allow minor versions to 
remain useful.


(It would also be good to remind committers that there was once a policy 
of escalating approvals that required two committers and two PMCs to ok 
an RC4 change. The problem change seems to have been unreviewed at RC4.)


I vote to fix rather than ripple the major version bug. To accommodate 
the wrong M6 version, consumers may need to widen to a [1.0.0,3.0.0) 
dependency bound for M6 and possibly M7 reverting back to [1.0.0,2.0.0) 
at RC1. Or just no bound at all as I suspect a few projects have done.


Regards

Ed Willink

On 13/03/2017 14:49, Tom Schindl wrote:

Well API-Tooling is correct! There is a method added to an interface who
was NOT marked @noimplement, so this is a source breaking change (binary
is ok!).

In general I think we should (re)instruct all our committers to think
twice before upgrading the major version of a bundle and get in touch
with their project leads, as breaking changes should only happen very
very rarely.

Tom

On 13.03.17 15:40, Brian de Alwis wrote:

I don't understand why the API tooling recommended a major increment
since there was no breaking change — they were all API additions.

Given that it's been in place for 10 days, my vote is to recover from
the mistake and fix the version number.

Brian.



On 13-Mar-2017, at 6:07 AM, Simon Scholz mailto:simon.sch...@vogella.com>> wrote:

Hello,

from my side I´ve just been following the checks of the API Base Line
tooling accroding to the changes in the generated code of the
MUiFactory class.
So at least we should add the noimplement flag to the MUiFactory to
avoid further major version increments due to the missing noimplement
flag.
But for now I think we should stick to the version increment to avoid
breaking clients who might have implemented MUiFactory, which anyways
is unlikely.

Regards,

Simon

On Sat, Mar 11, 2017 at 6:09 PM, Ed Willink mailto:e...@willink.me.uk>> wrote:

 Hi

 Chaotic major versions seem undesirable, so since the major
 version has not yet made it to +4 on any milestone it seems
 appropriate to revert it; preferably for M6, but certainly for M7.

 We aggregate to find inconsistencies. We found one, the platform
 was wrong, the platform should correct, not everyone else.

 Note that if the platform fails to revert, downstream projects
 that offer multi-release compatibility must forever remember to
 specify an irregular 1.0.0,3.0.0 range for this plugin.

 Note also that if PDE requires a major version change it usually
 means you should revise your code to avoid the major version, not
 just throw a major version to make the irritating error go away.

 Note also again that major version chnages should be announced so
 that consumers and experts have an opportunity to comment in a
 more timely fashion.

 Regards

 Ed Willink


 On 11/03/2017 16:52, Daniel Megert wrote:

 Thanks Tom!  That was my thinking too. So, that class should be
 marked as @noimplement in the model, because next time, PDE Tools
 will again ask the developer to increment the major version.

 Unfortunately, at this point, reverting the major version
 increase seems to do more harm than having a few bundles adjust
 their dependency. If someone disagrees, please let us know asap.

 Dani



 From:Tom Schindl 
 
 To:Cross project issues
 
 
 Date:11.03.2017 17:35
 Subject:Re: [cross-project-issues-dev] Problems with
 Simrel contributionre: org.eclipse.e4.ui.model.workbench
 Sent by:cross-project-issues-dev-boun...@eclipse.org
 
 



 Under NO cricumstance this API is/has/should be implemented by
 clients! IIRC it should be called at by none e4 internals. So
 this version increase is just plain wrong!

 Tom (guy who was in charge of the model)

 Von meinem iPhone gesendet

 Am 11.03.2017 um 16:22 schrieb Daniel Megert
 <_daniel_meg...@ch.ibm.com_ >:

 You're right Ed. At least in the SDK there's no re-export of that
 bun

Re: [cross-project-issues-dev] Problems with Simrel contributionre: org.eclipse.e4.ui.model.workbench

2017-03-13 Thread Tom Schindl 
Well API-Tooling is correct! There is a method added to an interface who
was NOT marked @noimplement, so this is a source breaking change (binary
is ok!).

In general I think we should (re)instruct all our committers to think
twice before upgrading the major version of a bundle and get in touch
with their project leads, as breaking changes should only happen very
very rarely.

Tom

On 13.03.17 15:40, Brian de Alwis wrote:
> I don't understand why the API tooling recommended a major increment
> since there was no breaking change — they were all API additions.
> 
> Given that it's been in place for 10 days, my vote is to recover from
> the mistake and fix the version number.
> 
> Brian.
> 
> 
>> On 13-Mar-2017, at 6:07 AM, Simon Scholz > > wrote:
>>
>> Hello,
>>
>> from my side I´ve just been following the checks of the API Base Line
>> tooling accroding to the changes in the generated code of the
>> MUiFactory class.
>> So at least we should add the noimplement flag to the MUiFactory to
>> avoid further major version increments due to the missing noimplement
>> flag.
>> But for now I think we should stick to the version increment to avoid
>> breaking clients who might have implemented MUiFactory, which anyways
>> is unlikely.
>>
>> Regards,
>>
>> Simon
>>
>> On Sat, Mar 11, 2017 at 6:09 PM, Ed Willink > > wrote:
>>
>> Hi
>>
>> Chaotic major versions seem undesirable, so since the major
>> version has not yet made it to +4 on any milestone it seems
>> appropriate to revert it; preferably for M6, but certainly for M7.
>>
>> We aggregate to find inconsistencies. We found one, the platform
>> was wrong, the platform should correct, not everyone else.
>>
>> Note that if the platform fails to revert, downstream projects
>> that offer multi-release compatibility must forever remember to
>> specify an irregular 1.0.0,3.0.0 range for this plugin.
>>
>> Note also that if PDE requires a major version change it usually
>> means you should revise your code to avoid the major version, not
>> just throw a major version to make the irritating error go away.
>>
>> Note also again that major version chnages should be announced so
>> that consumers and experts have an opportunity to comment in a
>> more timely fashion.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 11/03/2017 16:52, Daniel Megert wrote:
>>> Thanks Tom!  That was my thinking too. So, that class should be
>>> marked as @noimplement in the model, because next time, PDE Tools
>>> will again ask the developer to increment the major version.
>>>
>>> Unfortunately, at this point, reverting the major version
>>> increase seems to do more harm than having a few bundles adjust
>>> their dependency. If someone disagrees, please let us know asap.
>>>
>>> Dani
>>>
>>>
>>>
>>> From:Tom Schindl 
>>> 
>>> To:Cross project issues
>>> 
>>> 
>>> Date:11.03.2017 17:35
>>> Subject:Re: [cross-project-issues-dev] Problems with
>>> Simrel contributionre: org.eclipse.e4.ui.model.workbench
>>> Sent by:cross-project-issues-dev-boun...@eclipse.org
>>> 
>>> 
>>>
>>>
>>>
>>> Under NO cricumstance this API is/has/should be implemented by
>>> clients! IIRC it should be called at by none e4 internals. So
>>> this version increase is just plain wrong!
>>>
>>> Tom (guy who was in charge of the model)
>>>
>>> Von meinem iPhone gesendet
>>>
>>> Am 11.03.2017 um 16:22 schrieb Daniel Megert
>>> <_daniel_meg...@ch.ibm.com_ >:
>>>
>>> You're right Ed. At least in the SDK there's no re-export of that
>>> bundle.
>>>
>>> Dani
>>>
>>>
>>>
>>> From:Ed Willink <_...@willink.me.uk_
>>> >
>>> To:_cross-project-issues-dev@eclipse.org_
>>> 
>>> Date:11.03.2017 11:01
>>> Subject:Re: [cross-project-issues-dev] Problems with
>>> Simrel contribution
>>> Sent by:_cross-project-issues-dev-bounces@eclipse.org_
>>> 
>>> 
>>>
>>>
>>>
>>> Hi
>>>
>>> Correction. I misread the icons in the Plugin dependency view.
>>> Nothing
>>> in my workspace re-exports org.eclipse.e4.ui.model.workbench, so
>>> a major
>>> version change should be a simple MANIFEST.MF update for consumers.
>>>
>>>Regards
>>>
>>>Ed Willink
>>>
>>> On 11/03/2017 08:58, Ed Willink wrote:
>>> > Hi
>>>

Re: [cross-project-issues-dev] Problems with Simrel contributionre: org.eclipse.e4.ui.model.workbench

2017-03-13 Thread Brian de Alwis 
I don't understand why the API tooling recommended a major increment since 
there was no breaking change — they were all API additions.

Given that it's been in place for 10 days, my vote is to recover from the 
mistake and fix the version number.

Brian.


> On 13-Mar-2017, at 6:07 AM, Simon Scholz  wrote:
> 
> Hello,
> 
> from my side I´ve just been following the checks of the API Base Line tooling 
> accroding to the changes in the generated code of the MUiFactory class.
> So at least we should add the noimplement flag to the MUiFactory to avoid 
> further major version increments due to the missing noimplement flag.
> But for now I think we should stick to the version increment to avoid 
> breaking clients who might have implemented MUiFactory, which anyways is 
> unlikely.
> 
> Regards,
> 
> Simon
> 
> On Sat, Mar 11, 2017 at 6:09 PM, Ed Willink  > wrote:
> Hi
> 
> Chaotic major versions seem undesirable, so since the major version has not 
> yet made it to +4 on any milestone it seems appropriate to revert it; 
> preferably for M6, but certainly for M7.
> 
> We aggregate to find inconsistencies. We found one, the platform was wrong, 
> the platform should correct, not everyone else.
> 
> Note that if the platform fails to revert, downstream projects that offer 
> multi-release compatibility must forever remember to specify an irregular 
> 1.0.0,3.0.0 range for this plugin.
> 
> Note also that if PDE requires a major version change it usually means you 
> should revise your code to avoid the major version, not just throw a major 
> version to make the irritating error go away.
> 
> Note also again that major version chnages should be announced so   that 
> consumers and experts have an opportunity to comment in a more timely fashion.
> Regards
> 
> Ed Willink
> 
> On 11/03/2017 16:52, Daniel Megert wrote:
>> Thanks Tom!  That was my thinking too. So, that class should be marked as 
>> @noimplement in the model, because next time, PDE Tools will again ask the 
>> developer to increment the major version.
>> 
>> Unfortunately, at this point, reverting the major version increase seems to 
>> do more harm than having a few bundles adjust their dependency. If someone 
>> disagrees, please let us know asap.
>> 
>> Dani
>> 
>> 
>> 
>> From:Tom Schindl  
>> 
>> To:Cross project issues  
>> 
>> Date:11.03.2017 17:35
>> Subject:Re: [cross-project-issues-dev] Problems with Simrel 
>> contributionre: org.eclipse.e4.ui.model.workbench
>> Sent by:cross-project-issues-dev-boun...@eclipse.org 
>> 
>> 
>> 
>> 
>> Under NO cricumstance this API is/has/should be implemented by clients! IIRC 
>> it should be called at by none e4 internals. So this version increase is 
>> just plain wrong!
>> 
>> Tom (guy who was in charge of the model)
>> 
>> Von meinem iPhone gesendet
>> 
>> Am 11.03.2017 um 16:22 schrieb Daniel Megert > >:
>> 
>> You're right Ed. At least in the SDK there's no re-export of that bundle.
>> 
>> Dani
>> 
>> 
>> 
>> From:Ed Willink mailto:e...@willink.me.uk>>
>> To:cross-project-issues-dev@eclipse.org 
>> 
>> Date:11.03.2017 11:01
>> Subject:Re: [cross-project-issues-dev] Problems with Simrel 
>> contribution
>> Sent by:cross-project-issues-dev-boun...@eclipse.org 
>> 
>> 
>> 
>> 
>> Hi
>> 
>> Correction. I misread the icons in the Plugin dependency view. Nothing 
>> in my workspace re-exports org.eclipse.e4.ui.model.workbench, so a major 
>> version change should be a simple MANIFEST.MF update for consumers.
>> 
>>Regards
>> 
>>Ed Willink
>> 
>> On 11/03/2017 08:58, Ed Willink wrote:
>> > Hi
>> >
>> > On the one hand, this looks like the normal excitement that occurs 
>> > when a plugin has a major version increase; every consumer must follow 
>> > suit on its dependency bounds. However it is surprising that no 
>> > announcement has been made, particularly so close to M6.
>> >
>> > On the other hand, there are many plugins that re-export 
>> > org.eclipse.e4.ui.model.workbench and so they too must also incur a 
>> > major version increment. org.eclipse.ui.ide is one of them and I doubt 
>> > we want a major version increment there.
>> >
>> > Presumably a typo then. I suggest nobody apart from the platform team 
>> > reacts.
>> >
>> > Regards
>> >
>> > Ed Willink
>> >
>> > On 11/03/2017 08:19, Eike Stepper wrote:
>> >> Hi,
>> >>
>> >> It appears that https://git.eclipse.org/r/#/c/88492/ 
>> >> incremented the 
>> >> major version of the org.eclipse.e4.ui.model.workbench plugin. There 
>> >> are some other commits in the context of 
>> >> https://bugs.eclip

Re: [cross-project-issues-dev] Problems with Simrel contributionre: org.eclipse.e4.ui.model.workbench

2017-03-13 Thread Simon Scholz 
Hello,

from my side I´ve just been following the checks of the API Base Line
tooling accroding to the changes in the generated code of the MUiFactory
class.
So at least we should add the noimplement flag to the MUiFactory to avoid
further major version increments due to the missing noimplement flag.
But for now I think we should stick to the version increment to avoid
breaking clients who might have implemented MUiFactory, which anyways is
unlikely.

Regards,

Simon

On Sat, Mar 11, 2017 at 6:09 PM, Ed Willink  wrote:

> Hi
>
> Chaotic major versions seem undesirable, so since the major version has
> not yet made it to +4 on any milestone it seems appropriate to revert it;
> preferably for M6, but certainly for M7.
>
> We aggregate to find inconsistencies. We found one, the platform was
> wrong, the platform should correct, not everyone else.
>
> Note that if the platform fails to revert, downstream projects that offer
> multi-release compatibility must forever remember to specify an irregular
> 1.0.0,3.0.0 range for this plugin.
>
> Note also that if PDE requires a major version change it usually means you
> should revise your code to avoid the major version, not just throw a major
> version to make the irritating error go away.
>
> Note also again that major version chnages should be announced so that
> consumers and experts have an opportunity to comment in a more timely
> fashion.
>
> Regards
>
> Ed Willink
>
>
> On 11/03/2017 16:52, Daniel Megert wrote:
>
> Thanks Tom!  That was my thinking too. So, that class should be marked as
> @noimplement in the model, because next time, PDE Tools will again ask the
> developer to increment the major version.
>
> Unfortunately, at this point, reverting the major version increase seems
> to do more harm than having a few bundles adjust their dependency. If
> someone disagrees, please let us know asap.
>
> Dani
>
>
>
> From:Tom Schindl 
> 
> To:Cross project issues 
> 
> Date:11.03.2017 17:35
> Subject:Re: [cross-project-issues-dev] Problems with Simrel
> contributionre: org.eclipse.e4.ui.model.workbench
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> --
>
>
>
> Under NO cricumstance this API is/has/should be implemented by clients!
> IIRC it should be called at by none e4 internals. So this version increase
> is just plain wrong!
>
> Tom (guy who was in charge of the model)
>
> Von meinem iPhone gesendet
>
> Am 11.03.2017 um 16:22 schrieb Daniel Megert <*daniel_meg...@ch.ibm.com*
> >:
>
> You're right Ed. At least in the SDK there's no re-export of that bundle.
>
> Dani
>
>
>
> From:Ed Willink <*e...@willink.me.uk* >
> To:*cross-project-issues-dev@eclipse.org*
> 
> Date:11.03.2017 11:01
> Subject:Re: [cross-project-issues-dev] Problems with Simrel
> contribution
> Sent by:*cross-project-issues-dev-boun...@eclipse.org*
> 
> --
>
>
>
> Hi
>
> Correction. I misread the icons in the Plugin dependency view. Nothing
> in my workspace re-exports org.eclipse.e4.ui.model.workbench, so a major
> version change should be a simple MANIFEST.MF update for consumers.
>
>Regards
>
>Ed Willink
>
> On 11/03/2017 08:58, Ed Willink wrote:
> > Hi
> >
> > On the one hand, this looks like the normal excitement that occurs
> > when a plugin has a major version increase; every consumer must follow
> > suit on its dependency bounds. However it is surprising that no
> > announcement has been made, particularly so close to M6.
> >
> > On the other hand, there are many plugins that re-export
> > org.eclipse.e4.ui.model.workbench and so they too must also incur a
> > major version increment. org.eclipse.ui.ide is one of them and I doubt
> > we want a major version increment there.
> >
> > Presumably a typo then. I suggest nobody apart from the platform team
> > reacts.
> >
> > Regards
> >
> > Ed Willink
> >
> > On 11/03/2017 08:19, Eike Stepper wrote:
> >> Hi,
> >>
> >> It appears that *https://git.eclipse.org/r/#/c/88492/*
> incremented the
> >> major version of the org.eclipse.e4.ui.model.workbench plugin. There
> >> are some other commits in the context of
> >> *https://bugs.eclipse.org/bugs/show_bug.cgi?id=484398*
> but none of them
> >> seems to justify a major version increment. Maybe I overlooked
> >> something historic that justifies it. Is it justifiable that the
> >> major version of this plugin was incremented, and if so, what is the
> >> justification?
> >>
> >> At this point it looks as if clients just need to increment their
> >> upper bound.
> >>
> >> Cheers
> >> /Eike
> >>
> >> 
> >> *http://www.esc-net.de* 
> >> *http://thegordian.blogspot.com* 
> >> *http://twitter.com/eikestepper* 
> >>
> >>
> >>
> >> Am 1

Re: [cross-project-issues-dev] Problems with Simrel contributionre: org.eclipse.e4.ui.model.workbench

2017-03-11 Thread Ed Willink 

Hi

Chaotic major versions seem undesirable, so since the major version has 
not yet made it to +4 on any milestone it seems appropriate to revert 
it; preferably for M6, but certainly for M7.


We aggregate to find inconsistencies. We found one, the platform was 
wrong, the platform should correct, not everyone else.


Note that if the platform fails to revert, downstream projects that 
offer multi-release compatibility must forever remember to specify an 
irregular 1.0.0,3.0.0 range for this plugin.


Note also that if PDE requires a major version change it usually means 
you should revise your code to avoid the major version, not just throw a 
major version to make the irritating error go away.


Note also again that major version chnages should be announced so that 
consumers and experts have an opportunity to comment in a more timely 
fashion.


Regards

Ed Willink


On 11/03/2017 16:52, Daniel Megert wrote:
Thanks Tom!  That was my thinking too. So, that class should be marked 
as @noimplement in the model, because next time, PDE Tools will again 
ask the developer to increment the major version.


Unfortunately, at this point, reverting the major version increase 
seems to do more harm than having a few bundles adjust their 
dependency. If someone disagrees, please let us know asap.


Dani



From: Tom Schindl 
To: Cross project issues 
Date: 11.03.2017 17:35
Subject: Re: [cross-project-issues-dev] Problems with Simrel 
contributionre: org.eclipse.e4.ui.model.workbench

Sent by: cross-project-issues-dev-boun...@eclipse.org




Under NO cricumstance this API is/has/should be implemented by 
clients! IIRC it should be called at by none e4 internals. So this 
version increase is just plain wrong!


Tom (guy who was in charge of the model)

Von meinem iPhone gesendet

Am 11.03.2017 um 16:22 schrieb Daniel Megert 
<_daniel_meg...@ch.ibm.com_ >:


You're right Ed. At least in the SDK there's no re-export of that bundle.

Dani



From: Ed Willink <_...@willink.me.uk_ >
To: _cross-project-issues-dev@eclipse.org_ 


Date: 11.03.2017 11:01
Subject: Re: [cross-project-issues-dev] Problems with Simrel contribution
Sent by: _cross-project-issues-dev-bounces@eclipse.org_ 






Hi

Correction. I misread the icons in the Plugin dependency view. Nothing
in my workspace re-exports org.eclipse.e4.ui.model.workbench, so a major
version change should be a simple MANIFEST.MF update for consumers.

   Regards

   Ed Willink

On 11/03/2017 08:58, Ed Willink wrote:
> Hi
>
> On the one hand, this looks like the normal excitement that occurs
> when a plugin has a major version increase; every consumer must follow
> suit on its dependency bounds. However it is surprising that no
> announcement has been made, particularly so close to M6.
>
> On the other hand, there are many plugins that re-export
> org.eclipse.e4.ui.model.workbench and so they too must also incur a
> major version increment. org.eclipse.ui.ide is one of them and I doubt
> we want a major version increment there.
>
> Presumably a typo then. I suggest nobody apart from the platform team
> reacts.
>
> Regards
>
> Ed Willink
>
> On 11/03/2017 08:19, Eike Stepper wrote:
>> Hi,
>>
>> It appears that _https://git.eclipse.org/r/#/c/88492/_incremented the
>> major version of the org.eclipse.e4.ui.model.workbench plugin. There
>> are some other commits in the context of
>> _https://bugs.eclipse.org/bugs/show_bug.cgi?id=484398_but none of them
>> seems to justify a major version increment. Maybe I overlooked
>> something historic that justifies it. Is it justifiable that the
>> major version of this plugin was incremented, and if so, what is the
>> justification?
>>
>> At this point it looks as if clients just need to increment their
>> upper bound.
>>
>> Cheers
>> /Eike
>>
>> 
>> _http://www.esc-net.de_ 
>> _http://thegordian.blogspot.com_ 
>> _http://twitter.com/eikestepper_
>>
>>
>>
>> Am 11.03.2017 um 03:24 schrieb Evgeny Mandrikov:
>>> Hello,
>>>
>>> I'm forwarding the following thread of discussion since seems that
>>> previous messages were not delivered to the list - "being held until
>>> the list moderator can review it for approval. The reason it is
>>> being held: Too many recipients to the message"
>>>
>>> And an update on subject:
>>> EclEmma has been re-enabled to unblock work of Andreas Sewe on
>>> _https://git.eclipse.org/r/#/c/84521/_
>>> Papyrus really seems to be a cause of a problem, because after
>>> re-enablement all builds are still green.
>>>
>>> Regards,
>>> Evgeny
>>>
>>> -- Forwarded message -
>>> From: Evgeny Mandrikov <_mandrikov@gma

Re: [cross-project-issues-dev] Problems with Simrel contributionre: org.eclipse.e4.ui.model.workbench

2017-03-11 Thread Daniel Megert 
Thanks Tom!  That was my thinking too. So, that class should be marked as 
@noimplement in the model, because next time, PDE Tools will again ask the 
developer to increment the major version.

Unfortunately, at this point, reverting the major version increase seems 
to do more harm than having a few bundles adjust their dependency. If 
someone disagrees, please let us know asap.

Dani



From:   Tom Schindl 
To: Cross project issues 
Date:   11.03.2017 17:35
Subject:Re: [cross-project-issues-dev] Problems with Simrel 
contributionre: org.eclipse.e4.ui.model.workbench
Sent by:cross-project-issues-dev-boun...@eclipse.org



Under NO cricumstance this API is/has/should be implemented by clients! 
IIRC it should be called at by none e4 internals. So this version increase 
is just plain wrong!

Tom (guy who was in charge of the model)

Von meinem iPhone gesendet

Am 11.03.2017 um 16:22 schrieb Daniel Megert :

You're right Ed. At least in the SDK there's no re-export of that bundle.

Dani



From:Ed Willink 
To:cross-project-issues-dev@eclipse.org
Date:11.03.2017 11:01
Subject:Re: [cross-project-issues-dev] Problems with Simrel 
contribution
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hi

Correction. I misread the icons in the Plugin dependency view. Nothing 
in my workspace re-exports org.eclipse.e4.ui.model.workbench, so a major 
version change should be a simple MANIFEST.MF update for consumers.

Regards

Ed Willink

On 11/03/2017 08:58, Ed Willink wrote:
> Hi
>
> On the one hand, this looks like the normal excitement that occurs 
> when a plugin has a major version increase; every consumer must follow 
> suit on its dependency bounds. However it is surprising that no 
> announcement has been made, particularly so close to M6.
>
> On the other hand, there are many plugins that re-export 
> org.eclipse.e4.ui.model.workbench and so they too must also incur a 
> major version increment. org.eclipse.ui.ide is one of them and I doubt 
> we want a major version increment there.
>
> Presumably a typo then. I suggest nobody apart from the platform team 
> reacts.
>
> Regards
>
> Ed Willink
>
> On 11/03/2017 08:19, Eike Stepper wrote:
>> Hi,
>>
>> It appears that https://git.eclipse.org/r/#/c/88492/incremented the 
>> major version of the org.eclipse.e4.ui.model.workbench plugin. There 
>> are some other commits in the context of 
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=484398but none of them 
>> seems to justify a major version increment. Maybe I overlooked 
>> something historic that justifies it. Is it justifiable that the 
>> major version of this plugin was incremented, and if so, what is the 
>> justification?
>>
>> At this point it looks as if clients just need to increment their 
>> upper bound.
>>
>> Cheers
>> /Eike
>>
>> 
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Am 11.03.2017 um 03:24 schrieb Evgeny Mandrikov:
>>> Hello,
>>>
>>> I'm forwarding the following thread of discussion since seems that 
>>> previous messages were not delivered to the list - "being held until 
>>> the list moderator can review it for approval. The reason it is 
>>> being held: Too many recipients to the message"
>>>
>>> And an update on subject:
>>> EclEmma has been re-enabled to unblock work of Andreas Sewe on 
>>> https://git.eclipse.org/r/#/c/84521/
>>> Papyrus really seems to be a cause of a problem, because after 
>>> re-enablement all builds are still green.
>>>
>>> Regards,
>>> Evgeny
>>>
>>> -- Forwarded message -
>>> From: Evgeny Mandrikov >> >
>>> Date: Fri, Mar 10, 2017 at 1:46 PM
>>> Subject: Re: Problems with Simrel contribution
>>> To: Grégoire DUPE >> >, Sravan K Lakkimsetti 
>>> mailto:sravankum...@in.ibm.com>>, 
>>> jfalterme...@eclipsesource.com 
>>>  
>>> >> >, emuel...@eclipsesource.com 
>>>  >> >, step...@esc-net.de 
>>>  >> >, cedric.b...@obeo.fr 
>>>  >> >, laurent.gou...@obeo.fr 
>>>  >> >, lorenzo.bett...@gmail.com 
>>>  >> >, vincenzo.case...@rcp-vision.com 
>>>  
>>> >> >, 
>>> francesco.guidi...@gmail.com  
>>> >> >, francois.le-fe...@cea.fr 
>>>  >> >, quentin.leme...@cea.fr 
>>>  >> >, vincent.lore