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

[Bernhard Reiter]

On Thursday 03 January 2008 14:40, Bram de Greve wrote:
> 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.

Okay, this sounds easy, I might look into trying this next time
if I had not read below that you had tried and it did not work.

> 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.

Okay, some tests with Thuban would be been cool.
At least running the test suite, as we do now.

> > 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.

> 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 ;)

Okay.

> 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.

Wonderful, it is better to not obstruct this fine work with the pressure
of a release then. 

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20080104/51a980de/attachment.bin