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

[Doug Way]

On Tuesday, March 4, 2003, at 02:52 AM, Daniel Vainsencher wrote:

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

Yes, those are basically the points I was getting at.

> 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?

Not really.  I'm not sure that the Visibility argument is that 
compelling, though.  I don't mind that much the idea of newbies being 
3-4 months out of sync with what alpha testers are using.  (As long as 
there are enough alpha testers to really test things.)  Although much 
more than 3-4 months might bother me.  I guess it's a matter of degree.

Okay, perhaps by Visibility you also mean the fact that a newbie's bug 
report might get fixed and released into a stable version sooner with 
frequent releases than it would have otherwise.

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

That does make some sense.  A "very good" release might be a good start 
before getting down to splitting up the image and other work, as 
opposed to a more average release.  A reference release of sorts.  And 
good PR, I suppose.

It would delay the "getting down to splitting up the image" by at least 
a month, though.  And I'm not sure it's *really* that important.  So 
I'm still on the fence, awaiting a few more opinions.

Post-3.5, people have mentioned quarterly releases as a possible goal, 
while others have mentioned releases every 6 months.  My original 
thought was either every 4 months or 6 months or so.  I kind of like 4 
months, actually... not quite as intense as every 3 months, but still 
reasonably rapid, certainly more rapid than the last several Squeak 
releases.  Whatever the interval, I also like the idea of a somewhat 
regular cycle, in which stuff that doesn't make it in time for the 
release gets put off until the next release, rather than delaying the 
release.

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

Yes.  Now that 3.4 is done, I want to get going on the harvesting tool, 
at least.  Although if we go with a one-month quick cycle for 3.5, the 
tool may not be done early enough to make a big difference.  (There 
would still be value in just getting it done, of course.)  We would 
probably have to do some fix harvesting by hand, at first.

In the meantime, I will try to outline a brief harvesting process (say, 
tomorrow), at least, that we could debate very briefly and then use to 
harvest things, by hand at first, and then use that process as a basis 
for the tool.

But we do need to decide on the 3.5 release timing very soon...

- Doug Way