[Squeakfoundation]3.5 release timing (was Re: Outstanding 3.4 bugs?)

[Daniel Vainsencher]

I think Ian raises an important point. We need to remember what goals
our releases are intended to achieve.

First of all, their importance is waning. This is a good thing, and has
several reasons. 
- Nobody is waiting for us to publish their cool application.
- Starting from a stable 3.4 image, a person can right now write a
script that loads his favorite packages from SM and his favorite fixes,
and get almost whatever image they want. This can even be put on SM and
thus shared, though it's not very well integrated because SM doesn't
have support for card versions/other amenities that may or may not be
required (Goran - ;-).
- Soon we will have dependencies, and people will maintain their own
"distributions".

What are releases still needed for?
- Newbies coming in without the knowledge to determine their own
environment. These are certainly no reason to have very frequent
releases. They're a moderate/weak reason to have one fix release, in
order to fix project saving, but I suspect most of the project saving
people of the world either can fix the bug from knowledge, or are
getting their image from squeakland, which I've heard has it fixed.
- A common reference platform for human communication (I have 7.8,
update 100023, and these loaded, and the Muffin Materialization demo
just doesn't work!). Doesn't require releasing very often, quarterly is
probably better than monthly, less confusion.
- A common platform for packages, in the presence of a process where
things are leaving the image, and becoming packages maintained by the
community. Ah. Since we don't yet know how it'll work, we just don't
know. I'll bet it won't require releasing very often at least until
we're in there removing the Browser, or Compiler. Nothing really should
care very much if Celeste is in or not.

So why are people (me included) clamouring for more frequent releases?
well, they all seem to be really asking for two things - visibility and
speed.

Visibility - we know where we are, what we have is more or less what
newbies are downloading, what we're using off the update stream is as
near as possible everything that's been reviewed.
Speed - get things harvested faster, get fixes/enhancements stabilized
faster.

Does anybody see any other reason to have very frequent releases?

The only thing here that depends on the releases, is the aspect of
making something nice for the newbie, and around quarterly would
probably be just dandy.

So what am I saying? I think getting one more release relatively
quickly, with just fixes, would be a good thing, because we'd have a
very good release out there, and be quite sure we can make those
whenever we want. Call me insecure, but I prefer to have a very good
release out there, and not a "maybe about the same, maybe not quite as
good" release, where we still depended on Scott. Then we can rest easy
and think about other things. Whether it takes 4 weeks or 8 isn't that
critical to me.

And then, we have some issues with our process, regarding speed and
visibility, that we should improve. Part of it is having a clear message
out there about how to get ones fixes in quickly (do all the work for
us, of course :-). Part of it is maybe some distributed way of getting
feedback, maybe without depending on a magic server somewhere spewing
reports.

Daniel

Ian Piumarta <ian.piumarta at inria.fr> wrote:
> 
> On Tue, 4 Mar 2003, Doug Way wrote:
> 
> > Hmm.  Having gone through the process (well, at least most of it), I 
> > suppose a one-month release might be barely workable if the goal was 
> > limited to fixes only as you say.  One problem has been coordinating 
> > things via email (such as new VM releases, getting problems fixed), but 
> > I suppose these things get better when people know what to expect after 
> > the first time through.
> 
> On a personal note I'll just mention that making a VM release takes me an
> entire day (while I recompile on four different machines and construct
> more than a dozen seperate archives, _very_ slowly and methodically to
> make sure I don't mess anything up too badly).  I wouldn't want to do this
> every single month.  (Consider the 3.4gamma1 release as an
> exception.)  Every quarter might be acceptable.
> 
> I realise that the VMs change much more slowly than the image itself and
> new VM releases are only really be needed when something in the VM related
> code (or the plugins) changes.  OTOH, it would be slightly confusing if
> the latest VMs had lower version numbers than the latest stable images
> (pretty much consistently, modulo the occasionaly four-week period when
> the versions coincide after a VM-related change).
> 
> I think the whole regular release cycle is a bad idea anyway.  Even with
> the current infrequent big releases I tend to lag behind the stable image
> by a version or two, since there's just not enough incentive to change
> until something is _obviously_ better (or new and exciting) in the latest
> image.  My most recent image change was from 2.3 to 2.8.  If releases were
> more frequent then deltas would be smaller and I'd be even less likely to
> notice new stuff or improvements and hence track the latest image.  I'm
> probably not alone in thinking/working this way.
> 
> Just my 2 centimes of a Euro worth.
> 
> Ian
> 
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation