shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: shale-view fix and process (was: ... 1.0.4 released)
Date Tue, 23 Jan 2007 23:12:09 GMT
On 1/23/07, Rahul Akolkar <> wrote:
> On 1/23/07, Greg Reddin <> wrote:
> > On 1/23/07, Matthias Wessendorf <> wrote:
> > >
> > > I am pretty fine with a 1.0.5 instead of ;)
> >
> >
> > Me too :-)
> >
> <snip/>
> I definitely understand the desire for the fix to be available (and
> released). But I am even more interested in the process. Framework
> releases are coarser granularity and need more cycles, but provide a
> nice one-stop shop for all artifacts that work together. Modules are a
> finer granularity, and we can perhaps be more nimble releasing them,
> but we haven't released them separately.
> I was really looking for a discussion whether we want to go the latter
> route here, because that will entail a new set of procedural bits to
> be worked out (such as whether the shale-view-fix.jar is made
> available separately, what is its version number etc.).

I can definitely see multiple sides to this coin.

In theory, it should be less work to roll a point-point (i.e. in
this case) release of an individual module (see below for discussions on
timing of such a thing) than doing an entire framework release.  If so, it
would be interesting to explore how we could set up processes to accomodate
this.  If it's going to end up being roughly the same amount of work for a
module release or a complete framework release, on the other hand, it
probably isn't worth specializing.

A second consideration is turnaround time.  Again in theory, we want to be
able to turn around very quickly on security vulnerabilities or showstopper
bugs (the SHALE-394 case seems awfully borderline because AFAICT it does not
happen on a Sun JDK).  This might be a reason to plan for module based
releases even if it is the same amount of work, because the risk of breaking
something else is somewhat less.

I think it would be worth exploring what it would take procedurally to do
something like this.  I suspect the most interesting part of that would be
the repository strategy ... but even there I suspect we could generally just
execute the change on (say) the 1_0_X branch and just tag the module release
sources.  After all, we can always retroactively branch later if need be.

The most important consideration for a module based release, in addition to
fixing whatever bugs you are claiming to fix :-), is to ensure that the
updated code works fine with all the other modules at their current release
levels, in addition to whatever the current state of the code (for those
other modules) is on the branch.  In other words, let's assume we had
checked in 3-4 patches on shale-tiger issues, but none of them had been
deemed worthy of a module release themselves.  When now faced with
(hypothetically) an "important" fix on shale-core, we would need to make
sure that the updated shale-core bits worked against the 1.0.4 release
version of all the other modules, plus the current state of the branch that
includes all the committed fixes so far.

This gets even more interesting later on ... let's assume at a point in time
we have five incremental module releases, spread across three different
modules.  The testing matrix starts to suffer from combinatorial explosion
pretty quickly, and starts to encourage doing an entire framework release
where we can focus on just the proposed bits working with each other as a
unit, not with all of the outstanding modules.

Given that, I suspect we should probably figure out how we would do an
emergency module release if it were ever necessary, but I suspect we'll find
framework releases to be the norm except under unusual circumstances.

Going for a 1.0.5 without such a discussion is jumping the gun, IMO.
> Its possible we will have other comparable scenarios down the road. So
> lets pause and use this to create a process which will last Shale a
> lifetime, or half.

I agree that 394 doesn't warrant an updated release by itself, unless its
impact is more universal than it appears to be (and those who ARE affected
can use the current code in the branch, trusting that the only thing that
might be different from the actual release bits is low risk bug fixes, not
features that are half way through being implemented.

In addition, you only announced 1.0.4 today ... let's let the world have a
chance to provide feedback so we can address all of the potential issues at
once, instead of spending the next three weeks doing daily releases as
individual bug reports come in :-).


> > Greg
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message