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