What to release? (wasy: DBFSet_atof_function resolved (again =))

[Bram de Greve]

Bernhard Reiter wrote:
> On Thursday 03 January 2008 02:12, Bernhard Reiter wrote:
>   
>>
>> I was wondering, because after a brief look it seems that the LC_NUMERIC
>> problem is not solved in WIP-pyhapelib-Unicode branch r2795 or was is
>> solved? Best would be to have a version which only change the pyshapelib
>> from swig to a manually coded python api, but keep the functionality as far
>> as possible.
>>     
>
>   

Indeed, the LC_NUMERIC fix disappeared when I rewrote dbflibmodule.c,
about a year ago in WIP-pyshapelib-Bramz.  However, it should only be a matter of calling DBFSet_atof_function
again in initdbflib.

Bernhard: "So you did not do any tests with Thuban?
(To find out if your pyshapelib interface really does the same?)"


No I didn't.  All I can tell is that I've been using the pyshapelib
library of  WIP-pyshapelib-Bramz at 2755 in our own lab and software
without troubles.  As far as I can tell from my own use, it has the same
interface as before and it never crashed.




> So I am still wondering which version to release for Thuban 1.2.1
> (which I would want to release quite soon).
> Candidates:
> a) Not merge the new pyshapelib back to trunk
> b) use /thuban/branches/WIP-pyshapelib-Unicode/thuban at 2795
>    Drawback: potentially LC_NUMERIC unstable, which is a regressing
>    less tested then
>    Advantage: More test exposure with the new code.
> c) use /thuban/branches/WIP-pyshapelib-Unicode/thuban at 2798 2799 or later
>    Drawback: in development, so not tested and ready for a real release.
>
> Before christmas b) seemed to be the best guess, I am now wondering if a)
> is better so we can properly wait until the waves for c) are done.
> Nothing keeps us from doing another Thuban release once we see fit.
>
> What do you think?
>
> Bernhard
>
>
>   

Here's a suggestion:
* What do we know?
- WIP-pyshapelib-Unicode at 2795 is a breaindead merge between of trunk @
2793 (as it still stands today) and WIP-pyshapelib-Bramz @ (2734:2755]. 
The latter has a stable pyshapelib (tested myself as I've been using it
over the past year without problems).  This however, misses the
DBFSet_atof_function in initdbflib.
- There's no need to add DBFSet_atof_function to the
WIP-pyshapelib-Unicode branch, as that branch is using another fix
already @ 2798.
* What can we do?
- make a final addition to the WIP-pyshapelib-Bramz with only the
DBFSet_atof_function fix in initdbflib.c.  We would arrive at rev 2800.
- merge WIP-pyshapelib-Bramz rev (2734:2800] with trunk.  This should be
straight forward.  It was when I did before.
- Virtually we are at the same point as WIP-pyshapelib-Unicode at 2795 with
the additional DBFSet_atof_function fix.
- if it passes the test, release.  Otherwise, back off and go back to
plan A?


ON SECOND THOUGHT:  Forget about my suggestion, because I've just somewhat tried it myself, and it borks =)  Go for plan A ;)

At any rate, the head of WIP-pyshapelib-Unicode is not ready for release.  We're not far anymore, but there's still some work to do.

Bramz