[Scons-dev] Time for a release?

[Kenny, Jason L]

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-bounces at scons.org] On Behalf Of Dirk Bächle
Sent: Wednesday, May 20, 2015 11:46 AM
To: scons-dev at 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

_______________________________________________
Scons-dev mailing list
Scons-dev at scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev