[Qgis-developer] A roadmap to QGIS 2.0

[Alex Mandel]

On 01/19/2011 02:10 AM, Micha Silver wrote:
> On 18/01/2011 16:04, Andreas Neumann wrote:
> 
>> Hi all,
>>
>> I like your enthusiasm. However, a release of 2.0 in September at
>> Fossgis, with two additional in between releases, sounds a bit too
>> ambitious to me. Maybe we also shouldn't put too much pressure on us
>> just because the Fossgis conference is happening. There should be a
>> release (maybe 1.8), but it should not be 2.0 in my opinion. Let's
>> save 2.0 until it is really ready and of good quality.
>>
>> Also, I would prefer fewer, more stable features and bug fixes, over
>> too many new features that aren't ready for the average user. To me
>> the switch to the new labeling and symbology engine is a priority (but
>> there is still a lot of work to do!), as well as the multi-threading
>> branch and the table joins. The new rasters and on-the-fly raster
>> reprojection would also be nice.
> 
> Even tho' I'm not a developer I would chime in with one comment,
> following what you said:
> 
> I'd like to see some version be declared "stable".   At this point, with
> the greatly improved maturity of QGIS, I think having a recognized
> stable version is more important than additional features. I wish that
> devs had 5 € for each time, on the maillist there was an answer "You
> prob has been solved in the next version, please upgrade". But that's
> not the answer that users want to read.
> 
> The QGIS project doesn't use the "release candidate" naming convention.
> And it seems that as soon as each release comes out, it is abandoned by
> developers, who direct their attention to new functionality in the next
> development version. Essentially each and every release is an RC, with
> fixes always being done in next up-coming version.
> 
> Isn't it time to have a stable QGIS ? Call it LTS, or stable or
> whatever. But users want to know that it will be supported for some
> time, with *no changes* in the GUI, a well known feature set, and
> including "backporting" of bug fixes, etc. Perhaps that should be the
> goal for 2.0?
> 
> Thanks,
> Micha

I think we probably need to step back and think about the development
process we have, if we want to modify it and how we want to name things.
The tricky part with the 1.x series was that a lot of the bug fixes
required changing the API (by addition or modification) and that bug
releases required full reinstalls. So it really didn't make any sense to
'backport' them to 1.0.x as that would require a complete reinstall.

Now GUI changes or significant branch merges might be considered a
different topic. I would tend to agree that minimizing GUI changes could
be a hallmark of a 'stable' release even if all sorts of stuff
underneath changes slightly. What I'm hearing from people, is that bug
fixes even if they tweak the api or require new stuff should be 2.0.x
and that only the merge of new features or major overhauls of UI/Core
components(Like changing save file structure) would earn a 2.x
designation. Under a plan like this we could do RC and when 2.x
finalizes it would be the new 'stable' version.

You can see how this dev model is a bit different than the current.
And to be honest might not work well for this particular project. I've
seen plenty of cases where stuff gets added to the python api to allow
some plugin to happen and that plugin is really useful that most users
want it. Maybe what we should do is maintain a GUI backward
compatibility (toggle to see new/old) so that icons etc only change on
major versions.

As for plugins, we really need to enforce the qgis-minimum version
property as a requirement and encourage plugin testing (maybe
unittests?) against versions it's supposed to work with.

On the Topic of when 2.0, I think a complete list of all things we want
done for 2.0 should be made and the PSC should declare 2.0 when those
are finished (Obviously with some leeway to not get 100% in certain cases).

Maybe how we do it now actually works, and we just need an overhaul of
how we number/explain it to the general users.

Thanks,
Alex