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

[Tim Fox <timvolpe@xxxxxxxxx>]

Hi Wayne,

Sorry for the late reply :(

On 13/03/14 18:35, Wayne Beaton wrote:

I appreciate your input.

Is it reasonable to expect a short description, list of new features, new and noteworthy, or some equivalent for every release on a four-to-six-week cycle?

We've narrowed in on four-to-six-weeks. Is this really what we mean, or is it more of a "release when we feel it's right" sort of vibe we're looking for?

The way we normally release in Vert.x is we have all our features and bugs in the issue tracker (now Bugzilla), we prioritise them, and work on them. Then, every 4-6 weeks we simply release whatever we have ready, so there's no real upfront plan or any special significance for any release , and don't really know what features/bugs are going to go into each release up front as priorities may change during the cycle. Basically each release is timeboxed.

I think it's important to note that these rolling 4-6 releases are not milestone releases (as that implies they are somehow leading up to as "big" release") - they are not, each release is just as much a release as any other and has undergone the exact same level of QA.

More comments in line.

On 03/13/2014 12:06 PM, Joakim Erdfelt wrote:

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).

In my mind "critical bug fix" falls quite comfortably into the "bugfix work" category :-)

Strictly speaking, in the current process new features or API changes would have to be captured (at least in coarse terms) in the review documentation. We could probably get away with minor API changes occurring during a review period.

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.

Frankly, this sounds like a plan theme to me.

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.

Actually, you don't know what I'm thinking :-)

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.

But are these iterations producing "releases" or milestones? Technical previews? I think that this might be a different--but still useful--example. I would expect that anything I'd downloaded based on an evolving specification is pre-release or technical preview, not an official release.

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.

<snip>

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

I disagree with this in the context of your example. It would be perfectly reasonable to make a plan item along the lines of "implement the current version of the spec" (maybe a little wordier than that) and then zero in on a particular version of the spec when you decide it's time to actually push out a release. At some point you have to put some stake in the ground. At that point, you update the plan to reflect that decision.

Again, though, I think that this is a different case. I think that this case is more about deciding how to deal with a "technical preview".

- Joakim

Eclipse Jetty Project

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

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects

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