[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
 Reporter:  martinl               |       Owner:  grass-dev@…              
     Type:  task                  |      Status:  new                      
 Priority:  blocker               |   Milestone:  7.0.0                    
Component:  Default               |     Version:  unspecified              
 Keywords:  standardized options  |    Platform:  Unspecified              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------

Comment(by mlennert):

 Replying to [comment:116 wenzeslaus]:
 > Replying to [comment:115 neteler]:
 > > I see the problem of no consensus here. Do we need to fork GRASS at
 this point or postpone the release forever? (irony flag on or off as you
 wish)
 >
 > My understanding was that we have or we are very close to consensus. I
 the last round, [comment:108 martinl] suggested "`raster` and (`raster_3d`
 or `raster3d`)" for options and elements (when leaving module names as
 they are). [comment:112 mlennert] agrees with not renaming module names
 (if I understand correctly).
 >
 > [comment:111 annakrat] and [comment:113 hcho] don't want the underscore
 for 3D raster, so this changes "`raster` and (`raster_3d` and `raster3d`)"
 just to "`raster` and `raster3d`". [comment:102 I] already said that I
 prefer `raster3d` over `raster_3d`. In my opinion such a common option
 name as one for 3D raster (common for me and name of one of the basic
 types) should not have an underscore. But [comment:114 glynn] does not see
 the point in not using underscore in case of `raster_3d`. So, this is the
 only unclear part depending on how strong is Glynn's opinion.

 Why only Glynn's ? For me that question goes both ways. I have to admit
 that I don't understand the opposition to raster_3d. Is this only based on
 aesthetics ? In terms of ease of programming and usability, I have the
 feeling that raster_3d is superior as it allows you to use the current
 parser behaviour to use abbreviations like r3 which raster3d doesn't.

 More generally, this whole issue shows to me what happens in an
 unorganised release process where we start to release betas without being
 sure that we are in a stable enough state to do so and then begin such a
 fundamental review such as this one very late into the process...

 Moritz

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:117>
GRASS GIS <http://grass.osgeo.org>