[Qgis-developer] Merging of incompatible changes

[jr.morreale at enoreth.net]

Le 2012-10-25 09:03, Andreas Neumann a écrit :
> Hi,
>
> This could be a solution. Release 1.9 this year (potentially a
> Christmas present) with the new features we have now and then 2.0 in
> summer or autumn 2013. We could do the feature freeze of 1.9 quite
> soon.
>
> Andreas

Hi,

Is there something as the "good" choice given the limited workforce 
available ?
Is the release's multiplication a good choice ? It has already been 
tried...

The frequent feedback I get from institutions using QIGS is that they 
want :
- bugfixes but no new functionalities
-> but new "useful" functionalities (just for their specific use cases 
of course)
- less frequent release to ease the software validation and their 
internal documentation process
-> but a faster, better, cleaner software

Hard to conciliate ! Even without a multithreaded 2.0 these companies 
will be asking backported bugfixes as described by Pirmin.

Multithreading has been waiting on the side for years, I recall showing 
the 1.5 multithreaded branch ! Now Martin is able to finally start 
getting it back in trunk, this task isn't postponable as it would 
depends on his future availability and it would be complicated by all 
the master changes done during this time.

The API is already broken, the segmentation of the work will just make 
the migration of the plugins longer. If a plugin is not ported to the 
cleaner and simpler API, it should be considered as unmaintained. Should 
the project slows its pace for fear of unusable obsolete extensions ? 
ESRI has made the choice of killing their gigantic Visual Basic plugin 
base, MapInfo MapBasic is often breaking compatibility, etc. so this 
kind of situation is not unknown by all our "big" users. The difference 
is that they pay for licenses.