[tahoe-lafs-trac-stream] [pycryptopp] #90: upgrade versioneer

[pycryptopp]

#90: upgrade versioneer
-------------------+---------------------
Reporter:  zooko   |          Owner:
    Type:  defect  |         Status:  new
Priority:  major   |      Milestone:
 Version:  0.5.29  |     Resolution:
Keywords:          |  Launchpad Bug:
-------------------+---------------------

Comment (by gdt):

 A few separate thoughts:

  * if there is any significant desire to install other than real releases,
 that's a clue that releases need to be more frequent.   If we're only
 talking about people doing development who want an easy way to upgrade
 many boxes, that's something else.
  * the rc, pre, post, etc. names have gotten out of control.  packaging
 systems have to cope with each new flavor.  There really needs to be a
 single standard published and agreed on (by freedesktop perhaps?).
 Personally I am a fan of the old-school GNU versioning scheme from the
 early 90s with numbers only, where 1.7.80 is an alpha release towards .8,
 and 1.7.90 is a beta release.  Things that are after a release but not
 heading to a future release are just not releases and don't get numbers!
  * git revisions are not version numbers.  They shouldn't be used in
 version numbers as if they had the necessary properties.  They are great
 to put in a .h etc. to be able to know where the bits came from, which is
 different.
  * git has a mechanism for this already; do git describe --tags, and if
 necessary make tags a bit more judiciously to make this come out right.
 But git's describe output isn't really right for versions, because it has
 dashes and tag names and that won't compare lexicographically (you have to
 figure out what is a number).  But the middle number is useful.
 Therefore, do N.M.80.G, where N.M is the old version, 80 means "alpha that
 isn't really alpha", and G is the count of commits that are in the
 snapshot that weren't in N.M.
  * playing games with hashes to make them sort is ridiculous.  It's
 putting crud in the source tree to make something that should not be
 expected to have a property have that property.  It's a neat hack to show
 that you can do it (reinventing hashcash :-), but I don't think it should
 be used.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/pycryptopp/ticket/90#comment:5>
pycryptopp <https://tahoe-lafs.org/trac/pycryptopp>