Could we push default as is as 2.3.5, and then merge slots and push that in a couple weeks? Then we could branch default as 2.3 prior to merge of slots?
On Wed, May 20, 2015 at 11:12 AM, Dirk Bächle <[email protected]> wrote: > 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 > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
