[Qgis-developer] Merging of incompatible changes

[Denis Rouzaud]

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 at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>