[GRASS5] features needed for 6.2

[Radim Blazek]

I agree with everything except 'slushy feature freeze' - it simply
is not feature freeze and we would just continue in development
next year. So I support TRUE feature freeze on april 30
and 6.1.0 release the same day.
If a realy important new feature appeares after the feature freeze it must
be discussed in the list and it can be added only after general concensus.

6.2.0 should be natively ported on Windows but without d.* modules.

I am not aware of missing features necessary for QGIS
or other third party applications.

Radim

On 3/29/06, Hamish <hamish_nospam at yahoo.com> wrote:
> 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
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>