Re: [Scons-dev] Time for a release?
Hello, As I expected this 2.3.5 to be released (this was 3 weeks ago), I didn’t yet add my latest merged pull requests to the patched 2.3.4 version we are currently using in our build farm, but this seems to have stalled. Dirk, what are your plans, should I wait or rather keep patching our 2.3.4 in the meantime? Thanks -- Alexandre > Le 26 mai 2015 à 12:59, anatoly techtonik a écrit : > > On Mon, May 25, 2015 at 2:04 AM, Bill Deegan > wrote: >> Thanks Gary! > > Yay! +1 =) ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
On Mon, May 25, 2015 at 2:04 AM, Bill Deegan wrote: > Thanks Gary! Yay! +1 =) ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
Thanks Gary! On Sun, May 24, 2015 at 1:27 PM, Gary Oberbrunner wrote: > Wiki's back up. > > On Thu, May 21, 2015 at 3:16 AM, Dirk Bächle wrote: > >> On 21.05.2015 05:20, Bill Deegan wrote: >> >>> William, >>> >>> Of course your vote counts! >>> It's open source. >>> >>> >> +1 :) >> >> Dirk >> >> >> ___ >> Scons-dev mailing list >> Scons-dev@scons.org >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > > > > -- > Gary > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
Wiki's back up. On Thu, May 21, 2015 at 3:16 AM, Dirk Bächle wrote: > On 21.05.2015 05:20, Bill Deegan wrote: > >> William, >> >> Of course your vote counts! >> It's open source. >> >> > +1 :) > > Dirk > > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > -- Gary ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
On 21.05.2015 05:20, Bill Deegan wrote: William, Of course your vote counts! It's open source. +1 :) Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
William, Of course your vote counts! It's open source. -Bill p.s. Plus you have a good first name so I give it a little more weight :) On Wed, May 20, 2015 at 4:45 PM, William Blevins wrote: > > On Wed, May 20, 2015 at 3:14 PM, Dirk Bächle wrote: > >> On 20.05.2015 20:35, Bill Deegan wrote: >> >>> 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? >>> >> >> Sure, I have no objections to that. After 2.3.5 we could also branch out >> from default to a "2.4" branch, and then merge the "slots" stuff only on >> that branch as a first step. So we would never risk to "taint" our trunk >> with merges that would be kind of hard to undo. >> If no problems show up with 2.4 we could then still merge it again to >> default, and continue from there towards 2.5 and 3.x. Just as an idea... > > > I think this is a good idea. Risk mitigation plus consistency with the > SCons version numbers~! > > Not that my vote counts ;) > > V/R, > William > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
On Wed, May 20, 2015 at 3:14 PM, Dirk Bächle wrote: > On 20.05.2015 20:35, Bill Deegan wrote: > >> 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? >> > > Sure, I have no objections to that. After 2.3.5 we could also branch out > from default to a "2.4" branch, and then merge the "slots" stuff only on > that branch as a first step. So we would never risk to "taint" our trunk > with merges that would be kind of hard to undo. > If no problems show up with 2.4 we could then still merge it again to > default, and continue from there towards 2.5 and 3.x. Just as an idea... I think this is a good idea. Risk mitigation plus consistency with the SCons version numbers~! Not that my vote counts ;) V/R, William ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
On 20.05.2015 21:20, Bill Deegan wrote: Dirk, Sounds great! Is that something you execute? :) Well, I'd be willing to try. ;) However, this definitely requires to have the Wiki available again, so I can lookup the single steps for the release procedure...and I'm not sure that I have all the logins/passwords, e.g. for uploading the final packages to SourceForge. So you might hear from me again soon... :) Other thing is, that I'll be away over the weekend...so I'd start today doing a few first checks, like ensuring that the generated docs are up-to-date. Release would then happen during the next week, maybe Thursday or so. Sounds good to everybody? Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
Dirk, Sounds great! Is that something you execute? :) -Bill On Wed, May 20, 2015 at 12:14 PM, Dirk Bächle wrote: > On 20.05.2015 20:35, Bill Deegan wrote: > >> 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? >> > > Sure, I have no objections to that. After 2.3.5 we could also branch out > from default to a "2.4" branch, and then merge the "slots" stuff only on > that branch as a first step. So we would never risk to "taint" our trunk > with merges that would be kind of hard to undo. > If no problems show up with 2.4 we could then still merge it again to > default, and continue from there towards 2.5 and 3.x. Just as an idea... > > > Dirk > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
On 20.05.2015 20:35, Bill Deegan wrote: 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? Sure, I have no objections to that. After 2.3.5 we could also branch out from default to a "2.4" branch, and then merge the "slots" stuff only on that branch as a first step. So we would never risk to "taint" our trunk with merges that would be kind of hard to undo. If no problems show up with 2.4 we could then still merge it again to default, and continue from there towards 2.5 and 3.x. Just as an idea... Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
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 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 > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
I agree.. sorry that my last e-mail was a little hard to read. I have to remember to proof read when I am running on a few hour of sleep. I always seem to forget when I am half asleep :-) Jason -Original Message- From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Dirk Bächle Sent: Wednesday, May 20, 2015 1:12 PM To: SCons developer list Subject: Re: [Scons-dev] Time for a release? 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 Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
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 Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
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? 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.* -Bill On Wed, May 20, 2015 at 9:46 AM, Dirk Bächle wrote: > Hi Bill, > > > On 20.05.2015 16:36, Bill Deegan wrote: > >> All, >> >> It's been a while since the last release and a number of fixes are in the >> repo, is it a good time for a release? >> >> I forget where we are with slots? Is that still on a branch or in >> default now? >> >> > the slots branch hasn't been merged yet. From my perspective the current > situation is as follows: > > - I agree that the basic fixes we have would justify a release v2.4 right > now. Current trunk seems to be reasonably > stable > - The slots changes seem to work basically, at least nobody else > complained after we added the getattr > wrapper for backward compatibility. > - Jason Kenny is still examining the impact on Parts. He refactored some > source code, but is still working > on some minor warts here and there...but over all it looked promising. > > So, I'd like to pass the token to Jason to hear what he has to say. The > questions we all should probably discuss together are: > > - Is there more work needed to get Parts going with this new "slotted" > version of SCons? > - If yes, what are the single steps...and also: do we have to block the > release for them? > - What is our basic plan for getting Parts synchronized with SCons again? > In some way, a new Parts release will > depend on SCons v2.4 and won't work with any version lower than that. > How do we tell the user, and how do > we plan the next release of Parts in relation to SCons v2.4? > > There's probably more, but I forgot. ;) > > Best regards, > > Dirk > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Time for a release?
I the question to me. - Is there more work needed to get Parts going with this new "slotted" version of SCons? I turned off the cache logic to help with speed up. This mean parts currently is running as if --load-logic=all was set. Ie load everything. There are two reasons for this.. one is the some code in Parts was saving state via a means that the new __slots__ usage prevents. I have backup for this. So no big deal. Another is that I am trying to look at how to make the data cache logic faster and to use less memory. - If yes, what are the single steps...and also: do we have to block the release for them? I need to sync current work in Parts with main git repro I need to update some tests and samples I think I have a test failure. I need to see what is wrong. I need to setup the main bitbucket "team" so there is a clean url to get at this. Ie the like we have a https://bitbucket.org/scons/scons vs the https://bitbucket.org/%username%/scons. I think I going to use SConsParts as the ideal Parts/part/prt/prts names is used as a private repro. Add a basic MD file for stuff like bootstrapping based on using the newer pip based setup.py, etc.. Need to see ( you have thoughts) if I can get parts to depend on SCons in some way with the pip script.. also need to see how to register Parts on pypy ( should be easy.. just need to take time) Nothing here I believe should block a Scons drop, as I have to support older drops at the moment. Until I make a new drop of Parts people will have to use 2.1 to 2.3 versions - What is our basic plan for getting Parts synchronized with SCons again? In some way, a new Parts release will depend on SCons v2.4 and won't work with any version lower than that. How do we tell the user, and how do we plan the next release of Parts in relation to SCons v2.4? So technically I can support scons 2.1 and above. I plan to drop support for anything but 2.4 going forward after the next drop. I have to support 2.1 at the moment internally because of an issue with builder copy logic on clone that started in 2.2 with an internal build at work. ( I am pushing them to address there custom builder so this issues does not happen anymore.. but it has been slow) I personally want to try to sync on issues I pointed out in my last e-mail to you about the directory copy issue I saw ( I did not see any response yet on that e-mail to you yet.. I can resend if needed).. and the node API as it is as I would like to see if we can clean up some stuff to get a better "dev" level API for stuff like getting various state that we can document to help make it easier for general user that are making builder, etc . Some basic stuff also like getting in a symlink node and some patches in some place in SCons that I have in Parts to get hardlink and symlink support on windows would also be really nice to get in as it general useful. Given the improvements in have seen in the __slots__ version of SCons from Dirk.. I would really push to see if we can use in 2.4. This is good step forward in memory and speed improvements Jason -Original Message- From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Dirk Bächle Sent: Wednesday, May 20, 2015 11:46 AM To: scons-dev@scons.org Subject: Re: [Scons-dev] Time for a release? Hi Bill, On 20.05.2015 16:36, Bill Deegan wrote: > All, > > It's been a while since the last release and a number of fixes are in the > repo, is it a good time for a release? > > I forget where we are with slots? Is that still on a branch or in default > now? > the slots branch hasn't been merged yet. From my perspective the current situation is as follows: - I agree that the basic fixes we have would justify a release v2.4 right now. Current trunk seems to be reasonably stable - The slots changes seem to work basically, at least nobody else complained after we added the getattr wrapper for backward compatibility. - Jason Kenny is still examining the impact on Parts. He refactored some source code, but is still working on some minor warts here and there...but over all it looked promising. So, I'd like to pass the token to Jason to hear what he has to say. The questions we all should probably discuss together are: - Is there more work needed to get Parts going with this new "slotted" version of SCons? - If yes, what are the single steps...and also: do we have to block the release for them? - What is our basic plan for getting Parts synchronized with SCons again? In some way, a new Parts release will depend on SCons v2.4 and won't work with any version lower than that. How do we tell the user, and how do we plan the next release of Parts in relation to SCons v2.4? There's probably more, but I forgot. ;) Best regards, Dirk ___ Sc
Re: [Scons-dev] Time for a release?
Hi Bill, On 20.05.2015 16:36, Bill Deegan wrote: All, It's been a while since the last release and a number of fixes are in the repo, is it a good time for a release? I forget where we are with slots? Is that still on a branch or in default now? the slots branch hasn't been merged yet. From my perspective the current situation is as follows: - I agree that the basic fixes we have would justify a release v2.4 right now. Current trunk seems to be reasonably stable - The slots changes seem to work basically, at least nobody else complained after we added the getattr wrapper for backward compatibility. - Jason Kenny is still examining the impact on Parts. He refactored some source code, but is still working on some minor warts here and there...but over all it looked promising. So, I'd like to pass the token to Jason to hear what he has to say. The questions we all should probably discuss together are: - Is there more work needed to get Parts going with this new "slotted" version of SCons? - If yes, what are the single steps...and also: do we have to block the release for them? - What is our basic plan for getting Parts synchronized with SCons again? In some way, a new Parts release will depend on SCons v2.4 and won't work with any version lower than that. How do we tell the user, and how do we plan the next release of Parts in relation to SCons v2.4? There's probably more, but I forgot. ;) Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
[Scons-dev] Time for a release?
All, It's been a while since the last release and a number of fixes are in the repo, is it a good time for a release? I forget where we are with slots? Is that still on a branch or in default now? -Bill ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
