[Qgis-developer] Merging of incompatible changes

[Radim Blazek]

On Thu, Oct 25, 2012 at 12:48 AM, Paolo Cavallini <cavallini at faunalia.it> wrote:
>> 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.

-1, of course let's release ASAP, but without creating future problems.

> 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.

And break the API again? The API should be stable at least 5 years
IMO. Postponing the vector API change to 3.0 means just pushing the
problems we have to solve anyway to future. We have already broken
API, if we know that a new important feature cannot be implemented
without an additional API change, such change should be done in 2.0
(especially if it is ready to be merged and there is a person willing
to do that).

As Martin wrote, multithreading may be easily disabled in case of
problems but the API should be ready for it, I believe.

I see three alternatives:

1) Refuse vector API break in 2.0, release 2.0 (with non vector API
break and plugins broken) hopefully in spring 2013,  start immediately
work on 3.0 with vector API break, release  3.0 (with multithreading
and vector API break and plugins broken again) in 2014-2015.

2) The same as 1) but postponing 3.0 release to 2018 (to avoid
breaking API and plugins too often).

3) Accept vector API break in 2.0, release 2.0 (with API break and
plugins broken) in spring 2013 (possibly with disabled threading in
case of problems).

My favourite is 3).

Radim