shale-view fix and process (was: ... 1.0.4 released)

[Rahul Akolkar <ra...@gmail.com>]

On 1/23/07, Greg Reddin <gr...@gmail.com> wrote:
> On 1/23/07, Matthias Wessendorf <ma...@apache.org> wrote:
> >
> > I am pretty fine with a 1.0.5 instead of 1.0.4.1 ;)
>
>
> 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.).

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.

-Rahul


> Greg
>
>

Re: shale-view fix and process (was: ... 1.0.4 released)

[Craig McClanahan <cr...@apache.org>]

On 1/24/07, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 1/24/07, Sean Schofield <se...@gmail.com> wrote:
>
> > 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
> > vote.
>
> And if something has changed that we do *not* want to release yet, we
> can branch from the last release and apply only those changes.


Agreed ... although if we are true to the idea that only bugfixes go on the
1.0 branch, and new stuff is on the trunk, this should not be an issue very
often.

Craig

(We're actually attempting this in MyFaces to fix a portlet bug in
> MyFaces Core 1.1.4, but it doesn't seem to be going anywhere atm...)
>
> --
> Wendy
>

Re: shale-view fix and process (was: ... 1.0.4 released)

[Wendy Smoak <ws...@gmail.com>]

On 1/24/07, Sean Schofield <se...@gmail.com> wrote:

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

And if something has changed that we do *not* want to release yet, we
can branch from the last release and apply only those changes.

(We're actually attempting this in MyFaces to fix a portlet bug in
MyFaces Core 1.1.4, but it doesn't seem to be going anywhere atm...)

-- 
Wendy

Re: shale-view fix and process (was: ... 1.0.4 released)

[Sean Schofield <se...@gmail.com>]

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

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

Sean

On 1/23/07, Craig McClanahan <cr...@apache.org> wrote:
> On 1/23/07, Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > On 1/23/07, Greg Reddin <gr...@gmail.com> wrote:
> > > On 1/23/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > >
> > > > I am pretty fine with a 1.0.5 instead of 1.0.4.1 ;)
> > >
> > >
> > > 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. 1.0.4.1 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
> > >
> > >
> >
>
>

Re: shale-view fix and process (was: ... 1.0.4 released)

[Craig McClanahan <cr...@apache.org>]

On 1/23/07, Rahul Akolkar <ra...@gmail.com> wrote:
>
> On 1/23/07, Greg Reddin <gr...@gmail.com> wrote:
> > On 1/23/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > >
> > > I am pretty fine with a 1.0.5 instead of 1.0.4.1 ;)
> >
> >
> > 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. 1.0.4.1 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
> >
> >
>