Hi Andreas!

"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Hi Göran,
> 
> > Anyway, there were several reasons for doing this short 
> > release - since the bugs in question were described as serious
> > for some of the Squeak users we wanted to get a better base
> > release before jumping into the "ripping the image apart" phase.
> 
> There certainly were (I didn't claim there weren't) - I was just giving a
> couple of answers to the question "Why not?" ;-)

He, well, then you surely forgive me for mistaking that as meaning you
were opposed of the fast 3.5 release. What I hope people can remember in
all this is that 3.5 was an *exception*. It is not this way we mean to
do releases. It was a reaction to people complaining about 3.4 and
saying that it was a bad release (due to these two bugs). And we didn't
want to live with a bad release during the whole "3.6
hold-on-it's-going-to-get-rough-cycle".

Personally I would like to drop the discussion on 3.5 - it's done.
Perhaps it was a bad move to call it "3.5" instead of "3.4.1" but
whatever, we learn.

> > Ok, excuse me for asking - but why were you quiet? Perhaps it 
> > would have been better if you spoke up earlier.
> 
> I guess this is meant towards Bert - if I may point out there have been
> various people requesting to hold the release of 3.4 for including the class
> builder fix (where I have to admit that I did _not_ agree on this) and I
> have personally made a case for including Anthony's changes into 3.5.
> Neither of those did happen with the response mostly being "no, it's too
> late already". 

I am not talking about that. I am talking about when we *planned* the
quick 3.5.
We specifically planned to only include these two fixes etc. And since
we were aiming for a robust release we wanted to make sure not to
slip-something-in-the-last-minut-oops-it-contained-bugs.

Like the UUID fix that haunted us for a while - it sure looked simple
enough. ;-)
 
> While I don't generally disagree with this argument it appears that
> following this logic there will never anything being posted to anything
> that's declared gamma/final. And again, I don't generally disagree with that
> either but then the question needs to be asked: What do you need that update
> stream for? And if you don't need it, then why not unify the migration path?

Personally I don't think there is/should be any rule about not posting
updates to a gamma release.

And personally I think that we can post updates to a final release - but
that makes it a so called "release branch" so you can't trivially get
back on the main track. Like 3.2.1, I mean we did it then didn't we?

> > Andreas - you must be aware of the discussions about the quick 3.5
> > release.
> 
> I certainly do but I also recognize emerging patterns ;-) No attempt has
> been made to define the role of the update stream for any gamma/final
> version and from the last two rounds it appears to me that there's never

Last two rounds? 3.2 and 3.4? Am I missing something, wasn't it used to
get 3.2.1?

> going to be any role for it. And, once more, I don't mind this - but if
> there's no need for it then we should review the evolution model we're
> following.

Sure, I think we should do that review regardless. :-)

> > Unfortunately 3.4 had some nasties in it and after long (in some ways
> > time wasting) discussions on the lists we came to the decision to do a
> > fast 3.5. Perhaps it was simply a mistake - obviously you are 
> > telling us it was.
> 
> Well, I am not. All I am saying is that there are reasons against "needless
> version hopping" and that we should be considering the migration paths more
> carefully if we want to live with short release cycles.

Se the other thread you created about update streams and SM. I wrote
something about that there.

> > It would have been immensely more useful for us to hear this 
> > before the release.
> 
> Speaking for myself (as always ;-) it's the cycle of 3.4/3.5 and the general
> inclinations showing from the guides that make me raise these points. I

Could you elaborate on the inclination bit?

> couldn't have voiced these earlier simply because there was not enough
> evidence that this is the way it's likely going to be. I had expected this
> to work out a little different and assumed that the general attitude of the
> guides would not be quite as conservative as it apparently is. And, one

I think the word "cautious" is better than "conservative". As long as we
don't have a solid testcode culture (but it is emerging) the only way to
see if something is "bug free" is to simply wait and see if there are
bugs reported. This means that in order to make a more solid release we
simply must force ourselves to be "conservative" as you call it. That is
at least my perception. 

We shouldn't be as conservative when it comes to 3.6 IMHO. The whole
*point* of being so conservative with 3.5 was to make sure it turned
into a "better 3.4" instead of "another release with a few killer bugs
in it" *so that* we can be less conservative with 3.6.

So... now is the time to roll up our sleeves and get to work. 3.5 is out
and (pray to God) no killer bugs will hopefully be found. *If there are*
then we definitely should take care of those by simply doing a release
branch (3.5.1) and post updates on it until it damn well turns quiet
IMHO.

I will (yes, I really promise) post a draft plan for 3.6 and this is
meant to spur up some discussions on how we should proceed. Because this
is going to get bumpy but I hope we are all clear on that this is what
we want to do.

> final time, I don't mind this but we should be reviewing our options in this
> situation. The fork of the update stream has been designed for an aggressive
> evolution model - if we're not following this model then it is just not
> appropriate.
> 
> > Come on - who is saying we shouldn't use the update stream? Nobody
> > whatsoever.
> 
> Hey, but _I_ am! Didn't you read my last message?! ;-)

Yes, I can read that but you sure are implying *we* are saying we
shouldn't use the update stream. And we *sure aren't*. So why are you
implying that? ;-) :-) (<= abundant smileys not to prolong a silly
discussion)

> Cheers,
>   - Andreas

Cheers, Göran