[GRASS5] features needed for 6.2

[Michael Barton]

This sounds like a good plan to me.

MIchael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Hamish <hamish_nospam at yahoo.com>
> Date: Wed, 29 Mar 2006 19:49:32 +1200
> To: <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] features needed for 6.2
> 
> 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
> 
> 
>