[GRASS-dev] GRASS 7 timeline [was: d.menu, d.ask]

[Hamish]

Glynn Clements wrote:
> Is there an expected timeline for 7.x?

That is entirely up to the fine folks on this list; I would guess that
when the time comes, we know & we do it. Maybe then is now? I would not
object to it happening as soon as the SVN server is up and running. (no
technical reason for that, just a nice time for it to happen)

my wishes for the GRASS 7.0.0 release
* native MS windows fully stable and equal
  - worthy of a major point release, if simply for the PR value
* wxPython fully implemented for all GUIs
  - no or minimal Tcl, for a consistent user experience
    keep Tcl as non-default, optional "oldgui" ??? (answer that later)
* no more interactive d.*, xterm GUIs, etc
* centralized $MAPSET/raster/$MAPNAME/element
* more?
  - would a new raster format mean a new major point? or ok as long
    as lib fns were backwards compatible with the old format? too much
    to ask to support both? or r.convert module, like G6's v.convert?

the raster format changes could mean a time of dual branch development
like we had for Radim+Markus working on 5.1/5.7/6 and most everyone else
working on 5.0/5.4. Markus may have some stern words about that. ;)


> If so, does that signify a point at which fundamental changes to the
> graphics architecture can commence?

I guess we could restate the question as do we want/need a GRASS 6.4
stable release, or should we continue in devel mode all the way to 7.0?

(FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a 
nice milestone once winGrass is usable. If no 6.4 is planned, then there
is no need for a new SVN branch for 7.0 devel, we just continue with
6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and
cull away)

[*] r.li could be safely backported to 6.2? Tcl GUI updates less so but
we shouldn't abandon them. I guess they will be the day-to-day GUI
during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing.
??

The 6.x problem is not with fundamental changes to the underlying
architecture, that is wide open during a development minor version, and
AFAIAC go for it. The issue is changing the user interface to the
extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no
longer works with "GRASS 6". So we are free to "get our ducks in a row"
now, and we should do that, we just have to make an effort to minimize
user pain as we go.

When it is apparent that we have reached the point where the effort to
maintain backwards compatibility is a big time+energy sink, we trigger
the start of GRASS 7 development, without regret.

 
> If not, i.e. if i.ortho.photo *has* to continue to work until such
> time that someone sees fit to write an alternative (if that ever
> happens), then the graphics architecture will forever be limited to a
> Tek4105 emulation, and I may as well give up now.

I think we can, today, clearly make a list of things that will not be in
GRASS 7. Firstly a list of lib fn families, and secondly a list of
modules. Presumably replacements GUIs for missing modules will come
on-line in proportion to the demand for module's functionality.


> IMHO, I don't think that we can wait forever for decent graphics. The
> biggest danger is that the "you can't remove that because someone
> still uses it" problem will end up solving itself when no-one actually
> uses GRASS any more. I'd prefer people to set achievable goals than to
> insist on having everything and ending up with nothing.

We just have to call it GRASS 7. As that is just a number it is simple to
change. No need to artificially slow down development to keep 6.x alive.
e.g. People with need for GRASS 5.4 can still use that if they want,
without loss of functionality, new devel switching to GRASS 6 hasn't
changed that. And GRASS 7 devel won't hurt those who still want to use
GRASS 6. So no worries.



Hamish