Long, long ago, in days of yore, I was brought up using 3-level version numbers: XX.YY.ZZ

  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.

    - This was incremented only when an internal interface changed.

    Eg. The number or types of paramaters to an Internal Use Only function changed.

    Or a piece of common code was factored into a new subroutine ( Of course, we didn't call it factoring back then).

    Or, new IUO functionality was added that was not (yet) exposed externally through the documented API.

  3. Minor: ZZ - Zeroed when midor increments.

    - Incremented every time a modification was made that made no changes to internal or external APIs. Eg. Bug fixes, corrections, simplifications.

Increments at any level are only made once unit/system and regressions test suite have been run and passed.

Occasionally, if large numbers of bug fixes or enhancements meant that midor or minor were approaching 3 digits, then a "maintainance increment" of the next higher level was made to avoid that.

So far, I not seen a better system.

The upshot is, the version of your subpackages should live their own lives and be pretty much unrelated to the versioning of the parent.

However, a change in the major (XX) version number of a subpackage should result in an increment in the the midor (YY) of the parent.

If both subpackages modify their external interfaces, then both their major version increment, and the midor of the parent is incremented twice.

(Though if you want to avoid major woes, you modify one subpackage at a time, and then the dual increment of the parent becomes obvious.)

Update: The reason why I consider this a good system is because any code that uses (only) the published interface, will be compatible whilst the Major version number remains the same.

This is especially useful with dynamically link libraries as newer, but major version compatible .dll/.so files can be substituted for earlier ones without rebuilding the calling code.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

In reply to Re: Versioning modules in a package by BrowserUk
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.