shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Schofield" <>
Subject Re: shale-view fix and process (was: ... 1.0.4 released)
Date Wed, 24 Jan 2007 15:39:54 GMT
I think we should release all modules together and keep the numbers in
sync.  So if there's an important fix that can't wait in the core,
that just means releasing everything else as 1.0.5 too.  If nothing
has changed in the trunk for a module then its easy to just tag it and

This is what Spring does.  They generally don't have mismatched
numbers for their projects and when they do, its confusing.


On 1/23/07, Craig McClanahan <> wrote:
> 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 :-).
> Craig
> -Rahul
> >
> >
> > > Greg
> > >
> > >
> >

View raw message