Attack of the 50-foot reposturgeon

Well, I thought I was done hacking on this for a while. Then one of the projects I did a conversion for disclosed the existence of a second repo for their website, which I had to merge into the code repo. As a subdirectory. Which meant pushing all the file paths into a subdirectory. Which meant the new “paths sub” command; I wrote “paths sup” as its natural dual.

Also in this release: automatic preservation of untracked files under git and hg.

Fear the reposturgeon!

15 comments

  1. ESR, I am curious about your version numbering philosophy. Do you prefer the x.y style generally? Do you have a system for numbering minor revisions and major changes? Or just continue incrementing logically in points of 0.1 or 0.01

    I ask because it seems almost necessary to use some kind of version numbering for release commits while non-release commits simply have the generic commit IDs. Also do you put all your projects, including single file scripts into a git or hg repository?

    1. >Do you prefer the x.y style generally?

      I use the standard convention – x.y with y incrementing for minor releases and x for major ones.

  2. If you aren’t carefull, we’ll read about (from a third party) the Reposturgeon that Ate Eric Raymond!

  3. @hari:

    I know you specifically asked esr, but == FWIW, I feel that some projects put wayyyy too much thought into version numbering. Version numbers aren’t anything but arbitrary designations and they can be simply whatever you want and whatever makes sense for you and your codebase. I don’t think anyone can really tell you what works best for your project — that’s something to decide amonst you and your fellow devs.

  4. Prediction: Eric will have a forge coupled with a standard for admins to get data that they care about within two years. Such a standard will not involve consuming [x]html with regular expressions, rather, it will be a choice of JSON or downloading a dump. Every time I suggest XML I feel the urge to iron my hands.

    Basis: He can’t stand jailed forges, and keeps gnawing at a bone that should result in a feature that would be awesome in a forge. An easy transition from cvs to [foo] would be a very attractive feature, which is precisely what’s needed to convince people to break out of jails. Upon noticing an exodus, other forges will implement this standard. Problem freaking solved.

    Guess: It’s not going to take two years.

    Caveat: He might be hoping someone else implements this, after identifying the catalyst needed to cause an exodus from brain dead forges.

    Disclaimer: I’m probably wrong, but I’m sometimes correct when it comes to my predictions.

    1. >Disclaimer: I’m probably wrong, but I’m sometimes correct when it comes to my predictions.

      See my next blog post. :-)

  5. The NEWS file dates v1.9 at 2011-10-14. Am I wrong in thinking that this should be 2011-11-14?

    ESR says: Yup. Typo. I’ll fix.

  6. Revenge of the reposturgeon!
    Son of the reposturgeon!
    Night of the living reposturgeon!
    Reposturgeon from the Black Lagoon!
    Attack of the 50-foot reposturgeon

    You know…by his third movie, Godzilla had already mutated from ‘Destroyer of Tokyo’ into ‘Savior and Great Protector of Japan’. It would appear that the reposturgeon is a slow learner….

    Tell him he needs to be real careful when stepping on those power lines…

  7. Fear the reposturgeon? Reeeally? Might there not be even greater dangers to come? Horrors that stagger and bewilder the human mind?

    Ought we not most truly fear …

    Night of the Living Reposturgeon?

    Mwaahaahaahaaa!!!

  8. @Morgan Greywolf, yes, you have a good point. But I’d add that version numbering is also important for marketing purposes, sometimes – to let users know that this release represents something more than just enhancement of existing code.

    @esr, right. That x.y makes sense and seems a simple enough scheme. I supose after you reach 1.9 you continue with 1.10, 1.11 etc.

  9. I’d add that version numbering is also important for marketing purposes, sometimes – to let users know that this release represents something more than just enhancement of existing code

    Sadly, marketing is far too often an element in version numbering.

    The traditional distinction between “Major Version” and “Minor Version” has always been “Did we break anything?”. That is, if existing programs/macros/whatever written for version $foo.$bar will still run without modification, the new version will be $foo.$bas, where $bas > $bar. If the changes break existing functionality for any existing $foo.x, the new version should be $foo+1.0, so that everyone knows that the upgrade will not be painless.

    Marketing distinguishes between major and minor versions based on “How much are we charging to upgrade?”.

Leave a comment

Your email address will not be published. Required fields are marked *