Re: [cclib-devel] C bridge and changes to the progress updater

[Noel O'B. <bao...@gm...>]

On 9 February 2013 20:06, Adam Tenderholt <ate...@gm...> wrote:
>> The issue is just the fact that the API is changing in a way that is
>>
>> not backwards compatible. If software that previously worked with
>> cclib will now fail to work, we need to renumber the release to 2.x. I
>> know that it may only require a small change to the user's code, but
>> the API numbering is an implicit contract with the user, and it's
>> understood as such by users and the Linux distros. If you can figure
>> out a way that preserves the old behaviour while extending it to the
>> new improved way, then it's not a problem and can go in trunk and into
>> the next release. But to be honest, we can do a 2.x in the next few
>> months, I'm not suggesting postponing it indefinitely.
>
>
> I forgot that it's a bad idea to break backwards compatibility with a point
> release. I'll commit those changes to another branch. Somewhat related: I
> noticed that there is still a Qt3 progress class. I have no idea if it still
> works since I moved to Qt4 years ago. Do you think it should be removed now?
> Or wait until 2.x?

Well, I guess it might as well wait under 2.x. But you could do it on
the branch and I'll merge it after release.

>>
>> Another thing I was wondering about is whether your C code is going to
>> be specific to Python 2? It would be nice to start targeting Python 3.
>> I know I've mentioned this before, but I really think we need to get
>> onto Python 3 at this point, and it might be better to make the change
>> now (i.e. right after the release) if you are going to be writing C
>> code. The Python 3 branch in svn is in good shape, if a year or so out
>> of date, but it wouldn't take me long to sort it out.
>
>
> I think the bulk of the C API is fairly similar, although there are likely
> some minor changes necessary (e.g. int becomes long, string becomes
> unicode/bytes). Since your focus is probably to get the 1.1 release out, and
> then make sure the Python3 branch is up to date, I'll probably continue on
> the Python2 C functions and port to Python3 once we're more ready.

Ok, dok.

> Any idea of a timeframe for the 1.1 release?

Tomorrow is good for me, unless anyone objects. All I really need to
do now is package it up.

- Noel