Yesterday\’s post was perhaps a bit off the cuff. There were a lot of people really scared about my script, and I don\’t blame them. A lot of good points were brought up. It\’s not that I didn\’t consider them, it\’s just that they\’re already taken into account with how I do revision control. At least Luis had faith in me
Below is an example of how I tend to organize a project (my pre-1.0 releases are a bit different, so I\’m just leaving them out for the moment). There are effectively two kinds of tags, fixed (in black) and mobile (in red).
Notice that all the fixed tags are three-number versions. This means that if you request my-library_1.1.1.tar.gz, you\’re going to get that same code point all the time. However, you probably don\’t want to do that …
I hate that the three numbers are commonly referred to as \”major\”, \”minor\”, and \”revision\”. That carries no information what-so-ever. My own names for them are more like \”incompatible\”, \”enhancement\”, and \”invisible\” respectively. Increment the \”incompatible; number whenever you delete external symbols, change a method\’s parameters incompatibly, or some other change that prevents the previous style of use from working. Increment the \”enhancement\” number whenever new external symbols are added, or when compatible signature changes are made (EG, adding keyword args). Increment the \”invisible\” number when you add docs, refactor some methods, or otherwise make changes that don\’t affect the outside world.
This then means that when you declare a dependency on my-library v2.1, you\’re really saying \”using the second version of the interface with at least the first set of enhancements\”. So, version checking should make sure that the \”major\” version matches and the \”minor\” number is ≥ the one listed as a dependency.
Now, back to the chart. You\’ll see the red tags all float to the tip of a branch (yeah, that 2.0 tag is just at the end of a 0-length branch — humor me). So, with that graph, a dependency checker should basically look a the local version, see if it\’s 2.x, then make sure x ≥ 1. If it isn\’t, grab my-library_2.tar.gz. Or, if you\’re a bit more cautious, my-library_2.1.tar.gz. That way you get at least the interface required, with possibly some additional functionality, maybe some optimizations, etc.
Now, when you grab that archive, it should actually contain a directory called my-library_2.1.2. Notice how even though you only requested 2.1 (in the name of the archive), you now have the fixed tag in the package. This means that you can check the PGP signature for that exact version, and make sure it\’s cool.
To summarize: the fixed tags (used to name the directory in the tar) represent a precise point in the code and don\’t change. The mobile tags allow you to request only the parts you need to, and receive the newest compatible versions with all the fixes and enhancements that come along with it.
I hope that clarifies my position a bit. Thanks for all the feedback.