[Qgis-developer] Merging of incompatible changes

[Marco Hugentobler]

Hi

I understand Paolos and Pirmins concerns. Software like kde4 or gvsig 
had or still have a long time of problems with major new versions. On 
the other hand, I don't want to postpone the threading changes again and 
again.
Would it be an option to branch a 1.9 from current master just before 
Martin merges the first breaking changes? That way, there would be a 
version with all the nice 1.9 features and very little API breaks (and 
99% of the plugins working). Plus the shapefile encoding fix.
I remember though that the 1.9 option was shortly discussed in Essen and 
the release team was not very pleased about it. I can't remember the 
exact reasons, maybe it is worth to reconsider?

Regards,
Marco

On 25.10.2012 00:48, Paolo Cavallini wrote:
> Il 25/10/2012 05:39, Pirmin Kalberer ha scritto:
>> We did decide filling the missing gaps to fully replace old
>> symbology and old labelling (Paolo: Kickstarter pledge on the way?) and
>> polishing the many new features already integrated.
> Sorry, no progress on this. I've asked for some feedback and help, got
> none. Very little time now, planning to do it ASAP. Any help welcome.
>> plugins. It will take years to bring them all in sync with QGIS again.
> I understand both Pirmin and Martin concerns. I think seriously breaking
> the API and all the plugins will be good *if* we have a serious plan on
> how to migrate the plugins. At this stage, we cannot afford releasing a
> 2.0 without plugins, as nobody will use it, and we'll get stuck in the
> middle of the transition. This had proved to be a major problem for many
> software, sometimes effectively killing it, and we should really
> seriously avoid them.
> I think it is realistic, on the basis of the response to the request to
> move plugins to the new infrastructure, to assume that many developers
> will not do the migration in time: are we willing and capable of
> upgrading them ourselves, or do we plan to leave them as such?
>
>> We are on a developer list here. As a developer I like the proposed changes
>> very much. QGIS is made by developers, but is also made for users. And
>> sometimes we should care about users - even the 99% Windows users. That's why
>> I'm voting for a polished 2.0 release in a few month with the great feature
>> set we already have.
> +1: let's release ASAP.
> Please note that, as said in Essen, we can start preparing for a 3.0
> release as soon as 2.0 is out, no need to wait years for that.
>
> One side note: current stable version is basically unusable as a default
> for all double-byte-characters people (> half of the world population).
> The needed change is trivial, a new release could fix this easily.
>
> All the best.
>


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee