[GRASS5] features needed for 6.2

[Hamish]

Ok, trying to combine everyone's comments into a draft plan/roadmap:

We release 6.0.3 whenever it feels right, independent of 6.1+.

I think we agree that a 6.1.0 development release is a good idea and
should happen soon. This should be a CVS-HEAD tag and not its own
branch; aka the first beta release for what will be 6.2.0. We can
declare a feature freeze upon its release and then start working towards
something that will be 6.2.0-rc1. We stay in CVS-HEAD, no new branch is
created until we release 6.2.0-final. I think things worked really well
for the 6.0 release, with 5.1.0 etc, much better than I hoped actually.
After 6.1.0 it doesn't matter if we call it 6.1.1, 6.1.2, 6.1.3, ...; or
6.2.0rc1, 6.2.0rc2, 6.2.0rc3, ...; but I think 6.2rcX is more motivating
& focusing.

If we want, a feature freeze could be slushy -- minor features already
discussed but not yet fully coded and minor module enhancements could be
included for a time. Another possibility is to freeze the libs/core a
month before the modules or something.

I don't know what the GUI schedule looks like, but if the larger dust
starts to settle in two weeks time* (April 14), we should leave it
another 2 weeks to fix any bugs, then release 6.1.0 on April 30 and
declare a major-feature freeze in effect for the 6.2.0 release. We can
start monthly 6.2-rcX releases after that and look to a 6.2.0 release
after say rc5, in September or October. Sooner if it becomes obvious
that no more work is needed.
[*] Michael: is that realistic?


Details & issues:

Consensus is to include GEM and gis.m in 6.2.0. It would be nice to have
them both in raw form in the 6.1.0 development snapshot release, but
they don't have to be perfect for that.

Restructuring of the raster elements into a $MAPSET/raster/ dir means a
break to GRASS 7.0. It makes sense that this should happen in
combination with and at the same time as a revamp of the raster format
itself. That way we only have to do the transition once. (otherwise we
have GRASS 8.0, four times the backwards incompatibility ugliness, etc.)
Glynn: If you were to take this on, how does Oct-Dec this year sound for
starting work? "2007"? "2012"?

SQLite as default db: I think SQLite support is still too young and
lightly tested, and it is too important that it doesn't have problems.
Also I don't like the extra dependency. If consensus is that this should
happen at some point, I suggest it does in CVS in the *days after* 6.2.0
is released. But this is a catch-22 situation.. to get tested it needs
to be default, so if consensus is that it should be default for 6.2.0, I
think we need to make it the default ASAP.

New startup GUI: if it is ready by 8 weeks after 6.1.0 it can be in
6.2.0. Otherwise add it after.

GUIs for r.digit*, i.points: If ready in the 4 weeks after 6.1.0 is
released put it in for 6.2.0. If after that then wait until after 6.2.0.
i.e. We shouldn't wait for it to mature before we can release 6.2.
Same for a GUI frontend to g.gisenv and gis.m preferences.
[*] I take it you meant r.digit and not v.digit Michael?

d.m & gis.m: The day after 6.1.0 is released make gis.m the default GUI.
Keep d.m around until just after 6.2.0 is released.

gis.m GUI improvements (ie labels, etc) can probably keep happening
until about 8 weeks before final 6.2 release. ie (hypothetically) until
6.2.0-rc3 is released. lib/gis/parser.c changes need to freeze by 6.2rc1
I think.

d.out.png: Keep until the day after 6.2.0 is released. (user scripts)

Radim: anything big changes on the horizon needed for QGIS or the
Windows port? It would be a nice bullet point for all 6.2.0 core modules
(r.*, v.*, g.*) to work on windows native, but I don't think 6.2.0
should wait for it.

---

If he is happy to do so, I hope Markus will remain as release manager
and generally as the arbitrator in charge of final decisions.

I feel really good about where 6.1-cvs is right now; 64bit & large file
bugs are still trickling in (as expected), but otherwise things are
pretty strong.


?????

Hamish