Hi all,
I second Andreas with the idea of a frozen master version which is very
usable for end-users who need the last improvements.
Greetings,
Denis
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
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
