3.9.2 service release instead of 3.10.0 minor release for Luna?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

3.9.2 service release instead of 3.10.0 minor release for Luna?

Alexander Nyßen-2
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 
[hidden email] 

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
[hidden email]
https://dev.eclipse.org/mailman/listinfo/gef-dev

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.2 service release instead of 3.10.0 minor release for Luna?

Ujhelyi Zoltán
Hi,

+1 on both 3.9.2 and adding GEF4 to the next release train.

Cheers,
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2014.02.26., at 8:25, Alexander Nyßen <[hidden email]> wrote:

> 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:
>
> - [416909] Migrate to eclipse-jarsigner-plugin.
> - [416909] Switch to CBI releases repository.
> - [416909] Move signing profile to parent pom.
> - [416909] Removed unused profiles for testing.
> - [416909] Remove unused targets.
> - [NONE] Fixed javadoc could not be properly generated under windows.
> - [NONE] Fix Zest doc could not be properly generated under Windows.
> - [417188] Ensure SelectionSynchronizer only selects selectable EditParts.
> - [418315] Adopt target to Luna M2.
> - [418315] Add profile for Luna target to parent pom.
> - [394137] Add missing link to Zest 1.x snippets.
> - [NONE] Update to Eclipse SDK 4.4.0.I20131212-1600.
>
> 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 
> [hidden email]
>
> 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
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/gef-dev

_______________________________________________
gef-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/gef-dev
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.2 service release instead of 3.10.0 minor release for Luna?

Fabian Steeg-2
Hi,

+1 on both of these points from me too.

Cheers,
Fabian

On 26.02.2014, at 09:06, Ujhelyi Zoltán <[hidden email]> wrote:

> Hi,
>
> +1 on both 3.9.2 and adding GEF4 to the next release train.
>
> Cheers,
> Zoltán
> -- Zoltán Ujhelyi
> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>
> Fault Tolerant Systems Research Group
> Budapest University of Technology and Economics
>
> On 2014.02.26., at 8:25, Alexander Nyßen <[hidden email]> wrote:
>
>> 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:
>>
>> - [416909] Migrate to eclipse-jarsigner-plugin.
>> - [416909] Switch to CBI releases repository.
>> - [416909] Move signing profile to parent pom.
>> - [416909] Removed unused profiles for testing.
>> - [416909] Remove unused targets.
>> - [NONE] Fixed javadoc could not be properly generated under windows.
>> - [NONE] Fix Zest doc could not be properly generated under Windows.
>> - [417188] Ensure SelectionSynchronizer only selects selectable EditParts.
>> - [418315] Adopt target to Luna M2.
>> - [418315] Add profile for Luna target to parent pom.
>> - [394137] Add missing link to Zest 1.x snippets.
>> - [NONE] Update to Eclipse SDK 4.4.0.I20131212-1600.
>>
>> 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 
>> [hidden email]
>>
>> 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
>> [hidden email]
>> https://dev.eclipse.org/mailman/listinfo/gef-dev
>
> _______________________________________________
> gef-dev mailing list
> [hidden email]
> https://dev.eclipse.org/mailman/listinfo/gef-dev

_______________________________________________
gef-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/gef-dev
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.2 service release instead of 3.10.0 minor release for Luna?

Wienand, Matthias
In reply to this post by Alexander Nyßen-2
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 
[hidden email] 

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
[hidden email]
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
[hidden email]

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
[hidden email]
https://dev.eclipse.org/mailman/listinfo/gef-dev

signature.asc (565 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.2 service release instead of 3.10.0 minor release for Luna?

Stephan Schwiebert-2
Hi,

+1 from me, too.

Cheers,
Stephan

Am 26.02.2014 um 20:23 schrieb Matthias Wienand <[hidden email]>:

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 
[hidden email] 

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
[hidden email]
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
[hidden email]

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
[hidden email]
https://dev.eclipse.org/mailman/listinfo/gef-dev


_______________________________________________
gef-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/gef-dev
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.2 service release instead of 3.10.0 minor release for Luna?

Alexander Nyßen-2
Ok, then we will make it so. I will announce it on the cross-projects list for Luma M6, and if nobody objects there, I will:

- update the release plan (replace 3.10.0 with 3.9.2)
- change the feature versions in origin/master to 3.9.2.
- renamed origin/R3_9_maintenance to origin/R_Kepler_maintenance (so it gets clear that version 3.9.x is not bound to this branch, but that is was intended for the Kepler maintenance fixes that resulted in 3.9.1).
- update our website to document this in the Current Status section

Cheers
Alexander

Am 26.02.2014 um 10:29 schrieb Stephan Schwiebert <[hidden email]>:

Hi,

+1 from me, too.

Cheers,
Stephan

Am 26.02.2014 um 20:23 schrieb Matthias Wienand <[hidden email]>:

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 
[hidden email] 

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
[hidden email]
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
[hidden email]

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
[hidden email]
https://dev.eclipse.org/mailman/listinfo/gef-dev

_______________________________________________
gef-dev mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/gef-dev

--
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 
[hidden email] 

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
[hidden email]
https://dev.eclipse.org/mailman/listinfo/gef-dev

signature.asc (210 bytes) Download Attachment