2012/10/23, Denis Rouzaud <[email protected]>: > I second Andreas with the idea of a frozen master version which is very > usable for end-users who need the last improvements.
I second Andreas too. I'm currently finishing a project using 1.9-master because some bugfixes like the ones for bug #6550 or in commit 32978fb4, so keeping a version in OSGeo4W would be great for me, even if it is "frozen". > On 10/23/2012 09:23 AM, Andreas Neumann wrote: >> Hi, >> >> For me it is ok to go ahead and break the API. That was our goal for >> version 2.0. >> >> But perhaps we can especially mark the version before those big >> changes in github and create a parallel version in OSGeo4W that still >> works. I don't ask to work on two versions in parallel, just to keep a >> working version around for those who already work with master and want >> to continue using their improvements and plugins. >> >> Jürgen, can we organize a "frozen" parallel version in OSGeo4W before >> the big breaks? We can remove it again, once the situation gets >> stabilized in master. >> >> Andreas >> >> On Mon, 22 Oct 2012 21:17:20 +0200, Martin Dobias wrote: >>> Hi all >>> >>> recently I have been brewing some backwards incompatible API changes >>> that will 1) enable introduction of threading, 2) simplify API for >>> developers. I would like to merge the changes soon to master branch in >>> order not to drift too much from master. >>> >>> The changes will break lots of plugins, if not all of them... as a >>> part of the changes I would like to switch PyQt4 to use to QString API >>> 2 and QVariant API 2. Basically that means: >>> 1. all QString instances will be automatically translated to 'unicode' >>> python type and vice versa.... e.g. layer.name() will return 'unicode' >>> instead of QString. This removes the headache from distinguishing >>> between QString and native string api in python plugins. It also >>> avoids the common error of converting QString to 'str' type which >>> represents 8-bit strings (Qt equivalent is QByteArray) and so there >>> should be fewer errors in plugins related to handling of international >>> characters. >>> 2. QVariant instances from Qt are converted automatically... to get an >>> attribute of a feature, you would write feature[0] to get 'int' >>> instead of having to write f[0].toInt()[0] - definitely less clumsy. >>> Also let me note that the above mentioned API v2 are defaults in PyQt4 >>> for Python3, so once we choose to move from Python v2 to v3 there will >>> be less porting necessary. For more details please refer to: >>> >>> http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/incompatible_apis.html >>> >>> >>> >>> In general this means with these changes we will split everything into >>> two worlds: 'legacy' (QGIS 1.x release) and 'future' (QGIS 2.x). Until >>> now you can run all (most) plugins for 1.x also on QGIS from master >>> branch - but that will definitely change. What I am worried about: >>> 1. plugin repository - is it ready for QGIS 2.0? Is it possible to >>> keep a plugin in two branches of development: 1.x vs 2.x? Right now >>> you can distinguish just between stable/development version, right? >>> Maybe we should create another instance of the repository for plugins >>> for 2.x to keep them clearly separated? >>> 2. python plugins in QGIS source repository - mainly SEXTANTE - we >>> will probably need to create a branch to allow continuous development >>> of the plugins for QGIS v1.x and then port them to master. >>> 3. it will no longer be a good idea to recommend users to use qgis-dev >>> version because all the cool plugins they have downloaded will break >>> apart. But that's the cost of incompatible changes, right? >>> >>> What do you think, any ideas? >>> >>> Regards >>> Martin Best regards, -- Rafa _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
