1. Major: XX - this incremented only when the external interface to the code was changed or extended.
  2. Midor (middle order): YY - Zeroed when the Major version increments.
  3. Minor: ZZ - Incremented every time a modification was made that made no changes to internal or external APIs.

This looks like a great numbering system; I think I'll give it a try.

It's interesting to compare your XX.YY.ZZ system with Perl's major.minor.patchlevel system. Obviously, "midor" releases of Perl tend to change the external interface, although most old code seems to run fine. Major releases are few and far between, with no guarantees of backwards compatibility. Bugfix releases are fairly rare, which is kinda nice -- the interesting thing about fixing bugs in a language is that it does change the external interface, though not the way it's specified.

There's also the hidden semantics of the "midor" number's parity, where an even number indicates a "production" release and an odd number a "development" release. Until now, I'd never really thought about it, but on further reflection I don't like it. The "hidden" field annoys me. There's no reason not to cat on a "-devel" or "-release" tag on the version number -- or at least, none that I can think of.

It seems like your numbering scheme works best when there are a moderate number of releases and a lot of refactorings going on, and especially with internal-release code that isn't going to be used by the world at large. Putting the midor number (internal changes) ahead of the minor number (bug fixes) strikes me as a developer's way of doing things; customers wouldn't notice the internal API changes, but damn straight they'd notice the bug fixes. Perl's versioning system seems better for a slower-paced project, with lots of undocumented (at least in the version number) internal-development releases and a few major public milestones.

Here's another question: how does this sort of thing apply to a file format? After a very little reflection, it seems to me that every change in a format's syntax or semantics deserves a "warning - old files are probably incompatible" numbering change. Adding new stuff to the format -- provided that most parsers will be clever enough to warn-but-ignore stuff they don't understand -- won't break compatibility in the same way, so new features deserve only a minor increment. But that's bass-ackwards from the way I tend to think about version changes! What gives?

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
% man 3 strfry

In reply to Re^2: Versioning modules in a package by FoxtrotUniform
in thread Versioning modules in a package by legLess

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.