[Qgis-developer] Merging of incompatible changes

Andreas Neumann a.neumann at carto.net
Thu Oct 25 00:03:07 PDT 2012


 Hi,

 This could be a solution. Release 1.9 this year (potentially a 
 Christmas present) with the new features we have now and then 2.0 in 
 summer or autumn 2013. We could do the feature freeze of 1.9 quite soon.

 Andreas

 On Thu, 25 Oct 2012 07:50:43 +0200, Marco Hugentobler wrote:
> 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.
>>

-- 
 --
 Andreas Neumann
 Böschacherstrasse 10A
 8624 Grüt (Gossau ZH)
 Switzerland


More information about the Qgis-developer mailing list