[Squeakfoundation]KCP & 3.6

[Doug Way]

Daniel Vainsencher wrote:

>I disagree with the current calls to delay the release. If we wait for
>everyone to get whatever matters to them in, we might never make a
>release again :-) I don't see anything wrong with stuff waiting for 3.7
>- DecPools included.
>
>I know a few of us feel "in the middle of" various projects, but I think
>the release process has value too - it reminds us to clean the table
>every so often. I think between the KCP deprecations and the network
>rewrite, we've had enough change that it will do us good to focus on
>stability before we keep moving ahead.
>  
>

I was on the fence somewhat, but this sounds like a reasonable plan.  We 
will delay beta for a week or so, but stick to our final release date of 
August 1st.  There is some value in sticking to release dates unless 
there is a pretty big problem.

If the DecPools stuff feels like it's "ready", we could put it in now, 
otherwise we can put it in right at the beginning of 3.7alpha, which 
isn't too far away anyway.  (It sounds like there are still some 
outstanding issues at the moment...?)  I'll leave it up to Tim as to 
when it feels ready.

I actually wanted to at least get the Accufonts changes in for 3.6alpha 
also, which I don't think should be *too* destabilizing, and was on our 
3.6 plan.  I was going to work on that right after including the current 
batch of approved items (which I'll try to do today).  There are a few 
tweaks that I think should be made to the Accufonts stuff before it gets 
incorporated (for example I don't think it should change the default 
text size), so I was going to post my tweaked version as an [ENH] for 
people to try before rolling it in as an update.

I originally wanted to get the TrueTypeTextStyle stuff in as well, but 
there may or may not be time for that.  The items such as this on the 
3.6 plan which don't make it in will get pushed off to 3.7alpha.  But we 
could plan on listing them first on the 3.7 plan (say, before further 
package removals), so they'll be more likely to actually get done in 3.7.

>More generally - if we think about the process as a whole, not just the
>particular point in time were in, the only right kinds of reasons to
>delay the move to beta are "it doesn't meet our functionality goals". A
>more specific example is "without this new function, all of this other
>stuff we inserted makes no sense AND it is hard to remove that stuff".
>Only right kind of reason to avoid moving from beta to gamma is "this
>version doesn't meet our stability goals". Which I think should be "this
>version should be stabler than the previous one".
>  
>

("Previous" meaning 3.6gamma should be stabler than 3.6beta, or stabler 
than 3.5gamma?)

>So a one week delay of beta to insert parts of KCP that relate to what's
>already in makes a little sense. Delaying by a month just to get more
>stuff in now that the harvesting process is livelier, seems unjustified
>to me - we can get that after the version fork.
>

Yes... we can try to get most of the current KCP changes in this week, 
and then the next batch wouldn't go in until 3.7alpha.

>Speaking of which - at which stage do we create the 3.7 update stream?
>last time we did it on entry to beta, IIRC, yet some might say entry to
>gamma is more reasonable. What do we think?
>  
>

Good question.  I'd lean toward opening the 3.7alpha stream when we move 
3.6 to gamma... this is a good way to encourage people to use and test 
the beta version so that things actually get fixed.  And since the beta 
is only ~3 weeks long it doesn't seem like too big a sacrifice to not 
have an alpha version during that time.  It also simplifies update 
stream management a bit.  I could go either way on this, though.

- Doug Way