The odd/even number midor builds denoting development and maintainance tracks isn't that unusual. It serves to solve the parenial problem of separating the two which is essential for a developing product. You can only really avoid it once a product moves in to "Maintainance only" status.

In a nutshell, this is to solve the problem, that having just released a version; say 5.8(.0), you have four sets of changes to track:

  1. Bug fixes arising from customer discovery.
  2. Bug fixes from internal discovery.
  3. New and/or modified internal apis.
  4. New and/or modified external apis.

You need to be able to apply the first two to the last released build so that it can be sent out to customers with forcing them to wait for a new midor release to be tested, packaged and released. This allows small fixes that only affect a single file to be sent as just that file without compromising compatibility. If changes to internal or external apis are involved, it requires shipping a complete set, which effectively means a full release.

To accomodate the two tracks, it is necessary to fork the codebase. Whilst 5.8-maint and 5.8-devel are possible, it makes life hard in all sorts of small ways to have alpha designations. The consistancy (my favorite watchword) that comes from sticking with the same numbering scheme by going the odds/evens route can simplify many things.

Personally, I think I favour .50 nomeclature. At the release of 5.8, the codebase is split into 5.8.1 and 5.8.50--maintainance and development respectively. In a very large project, a 3 digit minor might be required, but usually not.

On the file format thing.

  1. If the file format changes in a way that is not backwards compatible. The interface has changed. That is a major version change.
  2. If within the existing file format semantics, new syntax can be added such that it will be parsed by older parsers, but not be functional, this is an internal api change. A midor increment is called for.
  3. Changes that correct mis-interpretations of the existing syntax or semantics to bring them in line with the published api's are minor changes.

The fly in that ointment is the case of a discrepancy between the published api and the way the parser parses the file, where the erroneous behaviour is found to be useful, or even preferable to the documented behaviour.

In this case, the answer depends on who discovers it, how big a customer they are, and how many others will complain if the documentation is brought in line with the code rather than the other way around. Pragmatism rules here.

The classic example of this was when DEC tried to drop support for a little known (and used) hybrid real-time/time-sharing OS they had called IAS (if memory serves?). Three customers complained when the announcement went out. DEC very pragmatically negotiated an agreement with the 3 customers that they would pay somewhat more for their service agreements in order to keep maintanance team going for a further 10 years.

A very pragmatic decision when the three customers were General Electric, General Motors and the US DOD!

I may have misremembered the details, but the basis of the story is true

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^3: 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.