[GRASS-dev] r39128 automatically choose appropriate geometry type

Helena Mitasova hmitaso at unity.ncsu.edu
Sun Sep 13 00:01:16 EDT 2009


On Sep 12, 2009, at 4:24 AM, Hamish wrote:

> Martin wrote:
>> it's debatable what should go to devbr6. We should be more focus
>> on GRASS 7.0. Very rough roadmap (my POV):
>>
>> 6.4 (~10/2009)
>> 6.5 (~03/2010)
>> 7.0 (~06/2011)
>
>
> my 2c pov:)
> 6.4.0: closed for new features, critical bug fixes only.
> 6.4.1: add a couple of features already in 6.5 and intended for 6.4
>   but not well enough tested for backport today. (those with tickets
>   who missed the train, but don't sell any new tickets)
>   Otherwise normal bug fixes only.
> 6.4.2+: critical bug fixes only.

I agree with this, I just have one question:

where do the current somewhat broken items in nviz belong in your list,
I am talking about
1. fixing sites with attributes handling (I think Maris has
been looking into it but I am not sure how difficult it is to fix it)
2. nviz crashing or freezing with reclassed raster (it should at  
least give
an error message and exit) - there was some discussion about it -
64bit issue? but I am not sure whether it was fixed
3. and a minor but annoying thing that nviz won't start from wxGUI  
(under File>NVIZ)
in winGRASS
Should we consider things that worked in 63 but don't work now critical?
Even if only few people may use them?

>
> it is tempting to allow things like an improved wxNviz, maybe we could
> be more relaxed with GUI vs. more strict with modules/libs. but at the
> same time it pays to be strict with a full critical-bug-fix-only  
> freeze
> sooner rather than later.
>
> no deep changes or refactoring should go into devbr6. (6.5)
>
> except in extraordinary circumstances all 6.x should be backwards
> compatible (at the module CLI level) in usage and behaviour with all
> earlier 6.x. Interactive features (ie GUI) does not have to be as
> strict because it can't be scripted/requires human decisions.
>
> 6.4.0 (~10/2009)
> 6.4.1 (~12/2009)
> 6.4.2 (~2/2010)
> 6.4.3 (as needed)

this is a good schedule, by the end of October we should be through
most of raster functionality in the class giving RC5 a good test run.
But we are not doing much v* and i* stuff and no db stuff - maybe we
should ask on users list to get it broadly tested, or somebody is  
teaching
class with more vector topics that could serve as testing ground?

Helena

>
> 6.5  not a release branch; just a useful dead-end.
>   "GRASS 6.5 (restricted development; testbed for backporting,  
> more...)
>   Utility version for developers, only available as source code."
>     (and power users/part-devels who need some stability)
>
> 6.5.0 devel. preview release (only if this time next year 7.0 isn't  
> out yet)
>
> 7.0 when it's ready. let's worry about release dates for it after 6.4.
>
>
> H
>
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



More information about the grass-dev mailing list