[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 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.

 [comment:113 hcho] suggests to allow shortening of options also where the
 numbers are. [comment:114 glynn] says that's possible.

 I hope I'm not misquoting anybody.

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