Re: [gef-dev] How to continue after Mars?

[Alexander Nyßen <nyssen@xxxxxxxxx>]

Hi team,

while not all team members have answered my initial post (see below) yet, it seems 1b) could be our release strategy to follow after Mars.

I checked with Wayne and if we provide a pure bugfix release (i.e. we do not add new functionality and do not change public API), we might plan a service release for Mars SR1 that does not require a release review. Technically, we could still label the GEF4 part of the release as 0.2.0 (to indicate we change provisional API) , but if we refer to the overall release as 3.10.1, labeling GEF4 as 0.1.1 could be more adequate.

As we are expected to provide Mars SR1 RC1 already at 17th of August, I have create an initial release plan (https://projects.eclipse.org/projects/tools.gef/releases/3.10.1-mars-sr1) that adds two milestones before RC1, namely M1 at 6th of July and M2 at 27th of July (the sim-rel release plan does not define any milestones prior to RC1).

I would further propose to defer any actions related to 2) and 3) to after the Mars SR1 release. That will give us enough time to set everything up properly before releasing for Neon.

Cheers

Alexander

 

Am 11.06.2015 um 15:52 schrieb Wienand, Matthias <matthias.wienand@xxxxxxxxx>:

Hi Alexander,

thank you for your work regarding the release!

I would opt for 1)b), i.e. shippinig one "bugfix" release before starting to work on new features as we currently have plenty of Bugzillas open. Besides, I think the effort of preparing the IP log justifies setting up Gerrit, and having more stability/customizability with the build system cannot be bad either.

Best regards,

Matthias

2015-06-09 14:32 GMT+02:00 Alexander Nyßen <nyssen@xxxxxxxxx>:

Hi team,

we are approaching Mars and you all know: after the release is before the release. As such, there are a couple of questions/decisions I would like to have your opinion on, related to how to continue after Mars:

1) Which release strategy do we want to choose for Mars SR1, Mars SR2, and Neon?

For Draw2d 3.x, GEF (MVC) 3.x, and Zest 1.x, we have always continued development in two two streams after a main release: the next main release has been developed in master branch and the SR1 and SR2 service releases in a respective maintenance branch, where we have only applied bugfixes that did not affect the API. I think it makes sense to keep it like this for the after-Mars timeframe as well. If some API extension to Draw2d, GEF (MVC), or Zest seems necessary, we can target a minor release for Neon, otherwise a service release will be sufficient. Whether we need a SR2 release will depend on whether concrete fixes will have to be added after SR1, so I would like to leave that open for now.

For the new GEF4 components, this procedure does not seem to be appropriate. I would thus propose to in this case not create a dedicated maintenance branch for Mars SR1 and SR2, but to continue our development in the master branch. I see two alternatives based on this premise:

a) Decide to not ship SR1 and SR2 releases of GEF4 (but reuse the Mars contribution) and directly aim for 0.2.0/1.0.0 with Neon.
b) Ship 0.2.0 for Mars SR1, skip Mars SR2 and instead aim for 0.3.0/1.0.0 with Neon after Mars SR1.

For me, b) seems to be the best alternative, as it would give us the option to deliver urgent fixes sooner than with Neon. Also, it would allow us to concentrate on a „bugfixing“ release first, before starting with the development of new features for Neon. We could still join the Neon simultaneous release after its M2 milestone, which would fit well into the simrel requirements.

2) Do we want to set-up Gerrit?

When preparing the IP log for the Mars release, I ran into several issues where contributions were not properly handled. I had to spend a lot of effort in getting these right. IMHO it could make sense to set-up Gerrit, as this would prevent such contributions to get into the code base. For committers, we could still allow to by-pass Gerrit, but all external contributions could be handled via it. On the downside, it could be harder for adopters to contribute, but it seems quite a few projects already use Gerrit, so that disadvantage could extenuate itself in the future.

3) Do we want our own Hudson HIPP instance? Do we want to discontinue drop-files support?

In the past we have always run into issues because we are still building on hudson-master. While our deployment scripts would have to be reworked, I think moving to our own HIPP instance could give us more stability. It would also give us the option to replace the promotion shell script I currently use with a dedicated promotion job.

I would like to rework the promotion scripts anyway, because I would like to turn our update-sites into composite-sites (to gain more flexibility in promoting dedicated builds to simrel). Also, I was thinking of discontinuing support for drop files, which we currently still provide for GEF, but not for GEF4. As the update sites contain all necessary artifacts, the old drop file mechanism seems to be quite outdated. In addition to disk space they also require maintenance effort, as they have to be archived on each new release. I would like to get rid of that burden.

Cheers
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
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: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino



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

--

Matthias Wienand
Fachinformatiker

Telefon: +49 231 9860 202
Telefax: +49 231 9860 211
Mobil:   +49 152 26802283

matthias.wienand@xxxxxxxxx
http://www.xing.com/profile/Matthias_Wienand2
http://www.itemis.de

itemis AG
Niederlassung Lünen
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: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino

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

--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer

Telefon: +49 (0) 231 / 98 60-202
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: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail