[Qgis-developer] Merging of incompatible changes

[Rafael Varela Pet]

2012/10/23, Denis Rouzaud <denis.rouzaud at gmail.com>:

> 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