[GRASS-dev] Re: [GRASS GIS] #587: svn versions should better reflect svn rev

[GRASS GIS]

#587: svn versions should better reflect svn rev
--------------------------+-------------------------------------------------
  Reporter:  hamish       |       Owner:  grass-dev@…              
      Type:  enhancement  |      Status:  new                      
  Priority:  normal       |   Milestone:  6.4.2                    
 Component:  Default      |     Version:  svn-trunk                
Resolution:               |    Keywords:  g.version, configure     
  Platform:  All          |         Cpu:  All                      
--------------------------+-------------------------------------------------

Comment(by hamish):

 > Replying to [comment:56 hamish]:
 > > Still, it is only relevant for svn (nightly) builds, and is redundant
 > > for final releases. It's fundamentally a dev branch aid.
 Replying to [comment:57 martinl]:
 > It's not right, it's not redundant for final release at all. Currently
 > users have no information what is the revision of their build
 (g.version,
 > wxGUI About window). It's common information which user could expect to
 know.

 It's completely redundant for a tagged release. In that case the version
 number of GRASS is all that is important and the svn version is simply an
 unused development artifact, 100% documented if they care to look it up
 (~10 sec in trac), but mostly irrelevant trivia to non-developers.

 I suppose someone with a random nightly build of 6.4.svn would not know if
 they are before or after a point release, or someone just saw a "fixed in
 stable branch r12345" and wanted to quickly know if their GRASS was newer
 or older than that, but that's about it.


 > > The release branch must be tested when .svn/ dirs and svn CLI tools
 are not
 > > present on the tarball/build machine. (in my quick tests last year I
 just su
 > > renamed those temporarily in /usr/bin/, see earlier comments in the
 ticket)
 > > It would not be nice to only discover a bug once the tarball was
 released and
 > > a non-dev tried it.
 >
 > This feature has been introduced 17 months ago (r39622). Recently
 backported to
 > devbr6 by you. What time is need to get finally this minor feature to
 release? ;-)

 you miss my point. it has been tested in developers' svn builds, but never
 outside of svn builds, which is what a point release is (svn export). A
 beta1 or RC1 release is a suitable time to test that, so if you want to
 take responsibility it, by all means go for backport now.

 And again, the primary value of this feature is in identifying custom svn
 builds, not final releases who's exact code-set is already known. (someone
 says there's a bug in 6.4.0rc2 you know ''exactly'' what assortment code
 they are talking about; if they say there's a bug in 6.5svn with no rev..
 how old is that? what code is that? maybe we can learn the year. that's
 why this feature is important in dev branches)

 anyway, nothing new to add, let's move on.


 tx,
 Hamish

 ps- I'd ask (everyone) that 6.4.1 tickets not be bulk reassigned to 6.4.2
 in trac until we deal to these tickets specifically assigned to 6.4.2
 already.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/587#comment:60>
GRASS GIS <http://grass.osgeo.org>