As far the SMLoader behavior - as agreed before, I changed the filtering
so that any package that has a category that is a prefix of the current
Smalltalk version will be displayed.

Since right now the packages are tagged as 3.4alpha, we'll lose them
all. I don't think we really care about that level of resolution, and
should move the packages to 3.2/3.4/.. style categories.

This shouldn't come up as an issue everytime we consider changing our
version status.

Ned, about the network issues you raised - I'm not sure we want to
address all of these in 3.4. I think we should assume that "stable" in
terms of a release means "significantly better than the previous final".
If Squeak's http requesting code wasn't industrial strength last time,
but the Mail related protocol classes were ugly too, I think we should
be happy if we get nicer mail this version, and let in the rest as it
becomes ready.

I think Michael's mail stuff may be applicable to 3.4, but that depends
on more testing (we don't want to find out too late the new
SocketStream/NetNameResolver code breaks Scamper, for example), and
Michael making a clean release of only what's tested. 

It's possible as far as we know that Michael wants to continue to work
on the HTTP stuff, and integrate the whole thing later. 

I personally think it would be better to test and integrate what we have
now - there'll be enough to do next version, too ;-)

Daniel


Scott Wallace <scott.wallace at squeakland.org> wrote:
> Friends,
> 
> My sense is that 3.4a can now reasonably be thought of as 
> feature-complete and pretty darned robust, so it would seem that we 
> are right on track for releasing 3.4/final before the end of the year.
> 
> Therefore, I suggest we carry 3.4 forward into beta as soon as is practicable.
> 
> When the version code advances to Squeak3.4beta, how will that affect 
> SqueakMap users right now?
> 
> If a package is registered for 3.4alpha, then presumably we would 
> also like it to be considered available for 3.4beta as well, without 
> requiring the package owner to re-register it.  (And the same issue 
> will very quickly arise again as we advance to gamma and then to 
> "final" 3.4.)
> 
> So is the SqueakMap-related corpus comfortable with this transition, 
> or is a little more tweaking required?  Do you want to maintain an 
> *ability* for a package to assert that it works, for example, in 
> 3.4alpha but *not* in 3.4beta?
> 
> AFAIK this is the only issue possibly standing in the way of moving 
> forward into beta right away.
> 
> Cheers,
> 
>    -- Scott