[Scons-dev] Time for a release?

[Dirk Bächle]

Bill,

On 20.05.2015 19:37, Bill Deegan wrote:
> Dirk,
>
> Are you suggesting we should merge slots into default and push 2.4?
> Or push what we have as 2.4 and then merge slots?
>

if I got Jason right we don't have to wait for Parts to synchronize our development, so we're free to latch on. I suggest that we 
now merge the slots branch into default and then release this as 2.4 (as was our original plan). As a next step we will then 
integrate the stubprocess.py wrapper (and not much more) and then quickly let another release 2.5 follow.

Like this, both minor version numbers signal that there is a (somewhat) bigger change, but without changing APIs or breaking 
existing scripts.

After that we're free to work on the 2.7/3.x version which we'll finally release as 3.0. This is what makes the most sense to me 
right now.

> I'm thinking since slots will (could) break compatibility for some that we should have a major version change? (3.0?)
>
> If I remember correctly, that was our criteria for major version number changes.
> Unfortunately that means 3.0 may confuse some with thinking python 3.0 is supported by the new (slots) version.
> (No need to discuss python 3.0 here, that's an entirely other ball of wax)
>
> *There are 3 broken tests on our win32 buildbot slave. We should resolve those prior to a release.*
>

I agree that we should ensure that there are no broken tests left. However I've seen those three tests to be a little flaky under 
Windows over time anyway. So maybe we should wait what the buildbots say after the "slots" merge?
We can then try to fix the tests or get them more robust.

In general, it would be good to account for another week or so of general testing, after the "slots" merge (and before releasing 
v2.4). It would be good if as many developers as possible could then try out the "default/trunk" version again on their projects or 
in general.

Regards,

Dirk