Re: [rt-pmc] Vert.x 2.1.0 release

[Joakim Erdfelt <joakim@xxxxxxxxxxx>]

On Thu, Mar 13, 2014 at 8:12 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:

I also would prefer to change the process if that's the right thing to do.

The current process requires a minimum of one week of community review and IP Log approval for every release. We have some flexibility with regard to review materials.

Can we reasonably assume that the last week before any release will be entirely testing and bugfix work (i.e. no new features) ?

Nope.  This is a bad assumption.

There are many valid cases for fast (sub 12 hour) turn around on critical bug fixes.

Timed from the point where the bug is filed to when the binaries are released.

And saying "no new features" is also a bad assumption, as that same bug fix might require new features (or even a changed API).

Do releases have anything like a plan? At the beginning of a release cycle, is there any conscious "this is what we're working on for the next four weeks"?

Not really, many projects have BIG goals and plans like "Support Servlet API 3.1" or "Add support for new Spec X".

These kinds of goals can often be declared, be worked on for over a year, with many interim releases before that goal is attained.

It can get even more muddy when working with spec bodies to implement a new spec.

Take for example websocket, Jetty was actively involved in the expert groups for all of the early pre-drafts, the experimental drafts, the final spec, and a half dozen related specs (websocket extensions and javax.websocket).  This goal "support websocket" took 5 years and 3 major releases of Jetty with entire trees of code being reworked twice.

I know what you are thinking, you should have broken this down more discretely for the release plan.

Unfortunately, when working with specs and drafts, its is common to have releases based on draft specs which can change based on knowledge gained, or even from misintepreting bad parts of the spec.  Fast iterations are common here.

So even declaring "Add support for WebSocket Hixie-75 Draft" would have been invalid within a few days of writing it, and we would have had to update the plan 3 times in that 1 week release cycle for the quick iterations back then.

Jetty releases are driven by:

  * java VM releases & updates

  * spec changes & updates

  * mobile OS releases & updates

  * browser changes & updates

  * networking changes & updates

  * bugs

  * features

In short, this Eclipse process isn't well suited for projects with dependencies external of Eclipse.

- Joakim

Eclipse Jetty Project