On Fri, Oct 29, 2010 at 6:56 AM, tsteven4 <tsteven4@qwestoffice.net> wrote:
I would rather base my customizations on a tagged release and 1.4.0, 1.4.1, 1.4.2 are all  problematic for me.  Post 1.4.2 versions of the trunk, with kml.c 1.06, appear to be usable.  Hence I was hoping for a release.  If the destabilizing work is done in the trunk instead of a branch it would be another point in favor of doing a release before the destabilizing commits start.

On the other hand I don't really know the effort or costs associated with a release so I can't appreciate those concerns.  I can get along with whatever you decide.

A release costs me between 10 and 15 hours.   While your changes are spiffy, they don't fix any user-visible problem or add any "must have" feature for most of our users.   I can't justify a release for them.  

RJL
 

Thanks,
Steve


On 10/28/10 7:22 AM, Robert Lipe wrote:


On Sat, Oct 23, 2010 at 10:58 AM, tsteven4 <tsteven4@qwestoffice.net> wrote:
This patch will prevent altitude units in kml output from being automatically scaled from m to km and ft to miles.  The bounds* test cases are updated for better coverage.

Thanx.  Applied. 
 
I know it has only been a few days, but do you have any ideas on a release schedule for 1.4.3?  kml.c 1.106 

There is none schedule yet.   Now that we seem to have iterated back to a stable release, I'd like to turn to internal restructuring of the code which will probably destabilize things. Thus, I don't foresee one in the near future.

Notably in the KML world, I'd like to scrap our open-coded reader/writer and integrate libkml.   It's huge, but it's so much more robust.

RJL