Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gef-dev] 3.9.2 service release instead of 3.10.0 minor release for Luna?
Hi,

+1 from me, too.

Cheers,
Stephan

Am 26.02.2014 um 20:23 schrieb Matthias Wienand <matthias.wienand@xxxxxxxxx>:

Hi,

+1 on both points from me, too.

Regards,
Matthias

Am 26.02.2014 08:25, schrieb Alexander Nyßen:
Hi team,

as you all know, we are currently spending all our efforts on getting GEF4 "on track". It seems that due to this we have so far only addressed three code-related bugs for GEF 3.x in the Luna release cycle, namely [424943] Fix creation of resize command by copy ignores some properties., [417188] Ensure SelectionSynchronizer only selects selectable EditParts., and [418350] Reexport org.eclipse.core.runtime to fix error in IDE, which all do not affect our API but are simple bugfixes beyond. All other changes in our master branch seem to be related to non-coding aspects only, thus they do not affect API-compatibility. In detail, these seem to be:


I had already decided to not contribute a dedicated 3.9.2 release to Kepler SR2 (and I have announced this here and on the cross-projects mailing list) but to re-use GEF 3.9.1 for the Kepler SR2 simultaneous release (as there haven't been any code changes after the 3.9.1 release to our R3_9_maintenance branch). From what has so far happened to origin/master (and can be expected until we reach M6 on 10th March), I was thinking of changing our Luna plan to contribute a 3.9.2 service release there instead of a 3.10.0 minor release (I already discussed the option with Wayne, and it seems it would be valid if we decreased our version numbers, which I have in anticipation already increased to 3.10 in our master branch, to 3.9.2 before M6 and change our plan accordingly). 

If nobody objects I think this would be the best option, as it would allow us to continue all efforts on GEF4 and would clearly document to our adopters were efforts are actually spent. My plan would be to continue this policy to only provide maintenance releases for the GEF 3.x code base from now on (otherwise I would have proposed that to be our policy after the 3.10.0 Luna release was released), unless some urgent fix or external contribution actually requires an API extension and justifies another minor release. 

Having said so, let me add that I think we should aim at including the new GEF4 components into the 2015 release train. 

Please comment!

Cheers,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nyssen@xxxxxxxxx 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

 



_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev



-- 
Matthias Wienand
Auszubildender

Telefon: +49 231 98 60 210
Telefax: +49 231 98 60 211

http://www.itemis.de
matthias.wienand@xxxxxxxxx

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev

Back to the top