Is it OK to interpret the generation count in a revision ID?

[Jens Alfke]

I’ve been assuming that document revision IDs are opaque, that the generation 
count prefix (“1-“, “2-“, etc.) is purely for troubleshooting. (I think I asked 
about this before.)

But now I see that the _revisions array returned with a document (with a 
“?revs=true” query string) removes those generation prefixes and requires you 
to re-attach them to generate useable revision numbers:

$ curl 'http://127.0.0.1:5984/db/714a54c3d7d7a0486557d03e1402b15f?revs=true’
   ...
   "_revisions”: {
       "start":3,
       "ids”: [
           "b613f5db612d6280d11c358ff9d073a7",
           "fe117f9b71157a03ce8aaa6b49fdf73d",
           "99eb6af272f7d854e55ff80c0b475fa9"
       ]
   }

In other words, the actual revision IDs are
        “3-b613f5db612d6280d11c358ff9d073a7”, 
        “2-fe117f9b71157a03ce8aaa6b49fdf73d”, 
        “1-99eb6af272f7d854e55ff80c0b475fa9”
so to get those I have to add code to iterate the “ids” array and prepend the 
generation number to each string.

Given that this format is baked into the protocol, may I rely on it for other 
purposes? It would be very useful to be able to look at two revision IDs and 
determine some (partial) ordering. I’m aware that conflicts mean that there’s 
no true ordering, but partial is better than nothing.

—Jens