Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Neon Maintenance Plans?
Hi, Benoit,

Okay, so there definitely is an intent to continue publishing Neon maintenance?  That is good to know.

It’s not an API breaking change, but a fairly significant API change nonetheless:  the superclass of an existing API class is changed from Object to a more specific type.  But, it isn’t strictly necessary to fix the bug (it was a nice improvement to do on the Oxygen branch where we have lots of new API anyways).  So, as of course I welcome contributions, I would like to encourage this contributor to simplify the patch, as I think it can be done without any API changes.  That, also, is a Good Thing™, I hope.  😉 

I’m not concerned about regressions in this case.

Cheers,

Christian

On Apr 27, 2017, 08:53 -0400, MAGGI Benoit <Benoit.MAGGI@xxxxxx>, wrote:

Hi Christian,

 

On this specific patch, I don’t see any API break. So I guess we can merge it?

Since you coded the patch for master, do you see any risk for regression?

ð  I think it’s a good  idea to merge bug fixes kindly reported by non-committer, it shows that we gladly accept help J

 

Version number:

Basically, I’m ready to follow any kind of guidelines.

 

I think that changing the Manifest version in the same commit as the code is a good practice to keep a semantic change in the same commit

but on the other hand it make the cherry-pick for patch report with gerrit quite impossible.

 

My vote would be for:

-        When making an API break, changing the number in the Manifest (we don’t want that to be reported easy peasy on a maintenance branch)

-        Otherwise not changing the number

-        Changing all numbers (conforming the report tooling [1]) (We can use X.100y.Z for master vs X.Y.Z for maintenance)

 

Also if we are aware at the start of a train (like oxygen), that we will break most of the API then directly bump all plugins in September.

(At the end of the day, only api break are important in our context)

 

Neon.4:

There is no date for a Neon.4 release (as far as I know),

but IMHO it would be very very very appreciated to have one including (when ready) the fix for model indexer [2].

 

Cheers,

Benoît

 

1 : https://hudson.eclipse.org/papyrus/job/Papyrus-Master-Developer/lastSuccessfulBuild/artifact/apireports/html/api.html

2: https://git.eclipse.org/r/#/c/93479/

 

 

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : jeudi 27 avril 2017 14:09
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [mdt-papyrus.dev] Neon Maintenance Plans?

 

Hi, Team,

 

There is a Gerrit review 95696 targeting the Neon branch that is looking to back-port a bug fix from Oxygen.  This raises some questions:

  • is there any plan to continue publishing builds of the Neon branch?
  • is there any plan to publish a Neon.4 (or whatever) release?
  • what about API changes?  This patch includes a (compatible) API change
  • what about version numbering?  I am assuming that this patch will have to be amended to update bundle versions for the changed plug-in bundles.  Did we ever decide on how the version numbers should be changed to reflect API changes in the Neon.x stream?

I have to admit, I would be inclined to reject this patch and to request an alternative solution that doesn’t make any API changes.  Thoughts?

 

Thanks,

 

Christian

_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

Back to the top