[Qgis-developer] bugfixing for 1.5

[Marco Hugentobler]

Hi all

+1 also for me to continue with more 1.x releases (until someone has a project 
that really nees to break the API.

> > It would be good to gather ideas what big changes should be done in
> > 2.0 besides the general cleanup of API.

A raster system redesign would be a good thing. But it could be done as 
rasterV2 and exist in parallel to the old raster system (similarly to 
symbology-ng or new labeling).

Regards,
Marco

Am Dienstag, 8. Juni 2010, um 14.11:14 schrieb Tim Sutton:
> Hi
> 
> On Tue, Jun 8, 2010 at 1:51 PM, Martin Dobias <wonder.sk at gmail.com> wrote:
> > Hi Tim
> > 
> > On Tue, Jun 8, 2010 at 10:16 AM, Tim Sutton <lists at linfiniti.com> wrote:
> >> BTW according to our Vienna discussions there would be no more 1.x
> >> releases after 1.5 since we were going to try to put out 2.0 by years
> >> end. We were going to make 1.9.x test builds moving up to that
> >> release. 2.0 would be a chance to do another api clean up and rip out
> >> old stuff (e.g. old symbology). Is everyone still happy to progress in
> >> this way or does this all sound like news to you, the hackfest having
> >> receded into the fog of time? :-)
> > 
> > I have the discussion from Vienna still in my weak memory :-) We were
> > planning the release 2.0 about the end of this year as we thought
> > there will be simply no other way to keep adding new features.
> > 
> > My personal impression is that we are not yet in a need to release 2.0
> > - features continue to be added incrementally and this trend will
> > probably continue for some more time. If we do few more 1.x releases,
> > the new features would also have more time to settle down and with
> > release of 2.0 we will only break the API, not the whole application
> > 
> > :) But maybe others will not agree with me.
> > 
> > It would be good to gather ideas what big changes should be done in
> > 2.0 besides the general cleanup of API. From the top of my head:
> > 1. replace old symbology with new symbology
> > 2. replace old labeling (no collision detection) with new labeling
> > (based on PAL)
> > 3. rework handling of vector features - to allow key-less tables,
> > multiple keys, table joins etc.
> > 4. rework geometries - to allow more natural and faster access to
> > geometries
> > 
> > For each of these items, there are reasons to postpone the transition:
> > 1. old symbology still has some features that new symbology doesn't have
> > 2. old labeling is much more configurable in comparison to new labeling
> > 3. AFAIK no work has been done yet
> > 4. it would be great to use Boost.Geometry c++ library instead of
> > GEOS, but it is not yet ready for our usage
> > 
> > Others will probably come up with more ideas (improvements to
> > organization of python plugins, refactoring of raster support etc.)
> > Hurrying with the release of 2.0 could mean that some of the important
> > changes will have to kept back and wait for 3.0...
> > 
> > Cheers
> > Martin
> 
> Yes agreed - you make a sound argument for plodding on with a few more
> 1.x releases then.
> 
> Regards
> 
> Tim


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Webereistrasse 66, 8134 Adliswil, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee