release number? (was: Christmas release? :))

[Bram de Greve]

Hold the presses! =)

Tonight, I've made significant progress to supporting the UTF-8 codec in
shapefiles (dbflib) using the way of ESRI's codepage files.
So, I should be able to move to full unicode support in Thuban now, but
I do have an important question concerning the pyshapelib API:

Each DBFFile instance has a codec attribute that tells the name of the
python codec used to encode/decode from and to unicode strings.
All strings pass to dbflib can be either unicode or regular strings, and
in case of the former they are encoded to regular strings internally.
So far, so good.

But what do we do with strings that are returned by dbflib?  Should they
be Unicode strings already (and break backwards compatibility), or
should be return the "raw" regular strings and let the caller do the
decoding (using the known codec).  That way, nothing changes for
existing code, and - maybe more importantly - if some DBF file carries a
language driver/codepage that is not supported by Python (or if the file
simply is corrupt), then all is not lost because the raw string is
returned and the caller may do whatever he's capable to salvage the data.

So, what do we do?  My preference goes the the latter, returning the raw
strings.

Bonus question 1: apart from the dbflib issues, what other areas of
Thuban are not yet fully unicode internally?
Bonus question 2: Bernhard, shall I make another branch where I commit
these recent developments?  Or do I commit it to my current branch?

Cheers,
Bram

Bernhard Reiter wrote:
> On Monday 26 November 2007 12:24, Bernhard Reiter wrote:
>   
>> I think we should prepare for a christmas tree release of Thuban.
>>     
>
> I am thinking about how to call this release, what is your opinion.
> Candidates I have come up with:
>
> 1.2.1
> 1.2.1beta1
> 1.3.0
> 1.3.0beta1
>
> There are arguments for all candidates:
> 1.2.1 would be suitable, because I think we have fixed a couple of problems
> since 1.2.0, so everybody should better try 1.2.1. Also it seems currently we 
> do not have that many users so might not need to care for too many branches
> and want to encourage them to test things.
>
> 1.2.1beta1 would be suitable because we know there are some problems with the 
> current state of Thuban. Notably with the encoding issues. Also we do have a 
> completely new pyshapelib implementation which has not seen that much testing 
> with Thuban, yet and could use some.
>
> 1.3.0 would be a way out and revive the "experimental" branch being an odd 
> number. What speaks against it is that there are not that many changes in 
> Thuban, so we might do inflation here and also there is no point in using 
> 1.2.0 anymoree with 1.3.0 out there.
>
> We could consider 1.3.0beta1 if we do the complete overhaul to internal 
> unicode yet.
>
> I am mainly undecided between 1.2.1beta1 and 1.2.1.
> With Free Software it is a good tradition to indicate the state of the 
> software and Thuban is "beta" right now, with somethings moving fast and 
> others not deeply tested. On the other hand, if someone would use 1.2.0 
> instead of 1.2.1beta1 because of the believe it would be more stable, it 
> would be bad as well.
>
> Opinions?
>
> Bernhard
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Thuban-devel mailing list
> Thuban-devel at intevation.de
> https://intevation.de/mailman/listinfo/thuban-devel
>