[Qgis-developer] A roadmap to QGIS 2.0

[Pirmin Kalberer]

Hi,

Am Dienstag, 18. Januar 2011, um 07.05:56 schrieb Tim Sutton:
> Hi All
> 
> I think its time to start thinking about getting 2.0 'out'. What do
> others think? The major goal would be to
> 
> - clean up the api and remove cruft / inelegant parts / backwards
> compatibility wrappers
> - do an overhaul of the api docs and get it to a good state (doxygen wise)
> - get rid of old labelling completely
> - get rid of old symbology completely
> - merge many of the plugins directly into trunk (north arrow, gps,
> coordinate capture, delimited text, georeferencer, some form of raster
> colours / 1 band raster colour table etc.)
> - capitalise on the bug fixing work of SunilRaj from kCube so that his
> time is going into stabilising for a 2.0 release
> - show the world that we have reached the next level of maturity and
> functionality
> -
> 
> As such I would propose the following time line
> (http://www.qgis.org/wiki/Release_Checklists)
> 
> Release Checklist 1.7 - Not yet named 	1 April 2011
>   Introduce threaded rendering, raster on the fly projection, 3D globe mode

Like Werner and Anita I've overlooked your entries "threaded rendering, raster 
on the fly projection, 3D globe mode" for 1.7. Hopefully Martin has time for 
this important merge soon!

* Version numbering: In my opinion version 2.0 should not be given from a 
developers point of view (code cleanup, etc.) but from a users point of view 
(new features, new GUI). In that sense 1.7 or 1.8 would deserve the version 
2.0 tag.
* API transition: From a users point of view we should keep compatibility to 
old project files and API calls (plugins!) as long as possible. We should give 
users as much help as possible to migrate their projects and developers to 
migrate their plugins to the 2.0 API. Therefore I would add the following 
points to 1.7:
-New symbology and new labelling used by default
-Deprecate old features (symbology, labelling) and API's

I propose adding a deprecation mechanism, which sends messages to the plugin 
manager. The plugin manager should mark plugins which are not 2.0 compatible 
and collect their deprecation messages. In contrary, C++ plugins will get 
deprecation messages at compile time.
So there would be time to update plugins after 1.7, complete the 
implementation of new symbology and new labelling and implement a migration 
mechanism for old features (good goals for a Hackfest!).

Regards
Pirmin



> Release Checklist 1.8 - Not yet named 	1 July 2011
>   Full GUI freeze for 2.0, no more old symbology, old labelling
> Release Checklist 2.0 - Not yet named 	1 September 2010
>   API changes finalised, all deprecation wrappers removed, API docs tidied
> up.
> 
> 
> The timing would allow us to have 2.0 ready to make a splash at the
> next FOSS4G conference.
> 
> Any comments? Does this work for others? Any other major additions
> folks think should be in place before QGIS goes out?
> 
> I look forward to your feedback,
> 
> Regards
> 
> Tim


-- 
Pirmin Kalberer
Sourcepole  -  Linux & Open Source Solutions
http://www.sourcepole.com