#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> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev