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
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
