[GRASS-dev] Re: [GRASS GIS] #392: backport G_is_c_null_value() to devbr6

[Paul Kelly]

GRASS GIS wrote:
> #392: backport G_is_c_null_value() to devbr6
> ----------------------+-----------------------------------------------------
>   Reporter:  hamish   |       Owner:  grass-dev at lists.osgeo.org
>       Type:  task     |      Status:  new                      
>   Priority:  major    |   Milestone:  6.4.0                    
>  Component:  default  |     Version:  svn-develbranch6         
> Resolution:           |    Keywords:                           
>   Platform:  All      |         Cpu:  All                      
> ----------------------+-----------------------------------------------------
> Comment (by hamish):
> 
>  Replying to [comment:2 glynn]:
>  > I suggest completely replacing null_val.c with the 7.0 version,
>  > and editing gisdefs.h to match. Either that, or leave it as-is.
> 
>  In that case, for the rc1 release I'd say leave it as is. It's too core a
>  fn to mess with so close to release time.
> 
>  For rc2, to completely replace null_val.c or not? I am still a bit unsure-
>  is there actually a bug in the current devbr6 version or is the idea to
>  keep the methods in sync to ease future maintenance?

Just a little comment about I'm not sure about the logic of 
intentionally planning to change a release candidate. To me, "release 
candidate" implies "this might be identical to the final release if we 
don't find any last minute bugs". If we're intentionally planning 
another change before the release it isn't really a release candidate 
after all. Maybe a pre-release would be a better name, e.g. 6.4.0pre1.

But I realise that doesn't really help anything towards the problem with 
slow and delayed releases. Personally I prefer more frequent releases 
even if there are known bugs, but it seems very hard to avoid the 
temptation to get last minute improvements into each release, which then 
necessarily delays the release while the last minute changes are tested, 
and things just tend to slip back further. More frequent releases may be 
a solution to that but I'm not sure.

Paul