# New Ticket Created by Will Coleda # Please include the string: [perl #52154] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52154 >
There was much discussion about this topic on #parrot today[1]. We have had many issues with the dealing with repository revision number checks, incorporating all the various ways we allow users to get our svn repository, with various VCS tools, including tripping over the "svk info" check. While Infinoid came up with a way to beat the svk info issue, we tried to take a step back and see why we were jumping through these hoops.[2] We were trying to insert the version into the built parrot so that we could get some very specific repository revision information out of parrot, e.g.: $ ./parrot --version This is parrot version 0.6.0-devel (r26569) built for nojit. <SNIP> And the reason for this is basically so that when we get reports from users, we can figure out which revision the problem was with. However: - releases will just say "0.6.0" here; we know how to get that version. - if it says "0.6.0-devel", we've (with our monthly release schedule) already got it narrowed down to a month's worth of commits. If they've grabbed one devel release, asking them to "svn up" or get another tarball is not onerous. Anyone looking at a *devel* version should reasonably be expected to deal with svn-latest. - If it's older than the last point release, asking them to verify against latest is ok, if we are unable to verify it ourselves. (We will change our strategy slightly here post 1.0, but we still won't need this level of granularity) Basically, user problems are reported against a *release*. Anyone reporting a problem against something more fine grained than a release is a developer, and we should expect them to be able to use their own version control tools, or re-rsync, or somehow coordinate with us. Please comment if you think we missed a critical use case on the revision number. So, given consensus on not needing the revision number... we can remove all the code for calculating, testing and displaying it: This involves: - removing Parrot::Revision (no need to track the svn revision anymore). (including no need to track pre vs. post configuration revision.), (and, if I read this right, Parrot::Revision::Utils) - tests of same. - config probe of same. - generation of src/revision.c (containing PARROT_REVISION), function declarations of those functions... - removing any references to PARROT_REVISION in the code base: compilers/imcc/main.c We do wish to keep PARROT_VERSION (generated for include/parrot/config.h), but any references to PARROT_REVISION must go. Since this isn't a feature, we can avoid the normal deprecation cycle and rip this out before the next release; Let's hold off a few days to give time for responses other than "+1", however. (but +1s are most welcome to avoid Warnocking). In the meantime, anyone who wants to put together a patch that implements the list above and attach it to the ticket will earn themselves a cookie, payable at YAPC::NA. =-) [1] http://www.parrotcode.org/misc/parrotsketch-logs/irclog.parrot-200803/irclog.parrot.20080326 :: search for "postconfigure" [2] Please note that we're not saying you can't interact with the svn repository using any of the various clients; We're just going to avoid jumping through some hoops that were just getting in your way anyway. -- Will "Coke" Coleda
