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.
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
