[gef-dev] How to continue after Mars?

[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