Posted by
michael
on from the some-data-loss-inevitable dept.
ulrikp writes "Swedish MySQL AB, makers of the MySQL database, have released an Alpha-version of their flagship, dubbed MySQL 5.0.0. The changesinclude basic support for SQL-99 stored procedures. Please note: Despite the version number, this is an Alpha release, and not for general consumption."
In the spirit of the interesting compatibility version numbering post, informative version numbering is straightforward. Every version of software should be go through alpha, beta and release versions, for each change. When starting to edit the source code, increment the version number first. The number to increment, whether.., is determined by kind of compatibility the change will discard from the previous version: major=GUI/features, minor = data formats / APIs, build/patch = bugfixes. Once the number is first incremented, it is an ALPHA version, for testing/revision within the group (even of one person) that has developed it (any designers or programmers). Once alpha testing is complete within the developer group, whose preconceptions influence their testing, it is a BETA version, for testing outside of the developer group (customers, end users, random taste tests). Once beta testing/revision is complete, when all revision is complete, it is a RELEASE version, for another round of idiot-check retesting, usually by the release team testing with the packaging and distribution tools, with marketdroids given a more serious voice, when they take responsibility for unleashing it on the market. When alpha, beta or release phase revisions change compatibility with the previous version's GUI/features or data formats / APIs, the major or minor version number, respectively, is incremented, and it goes back to alpha testing. So an app might have version numbering like:
The versions released would be known only as 2.3, 2.3.1, and 2.4.5. 2.3 would be binary compatible with 2.3.1, and the same GUI and features, but 2.4.5 would only look and feel like 2.3, without binary compatibility (either data formats or APIs). This scheme makes version numbers actually useful, to consumers, new developers, and even automated interoperability systems (a la apt-get). It also offers an incentive to keep version numbers lower, as higher numbers reflect more changes (get it right the first time). At least in the minor and build/patch numbers. Most importantly, it reflects a reasonable test/revise/release discipline. So the numbers are the tail, wagged by the dog.
Slashdot Mirror
In the spirit of the interesting compatibility version numbering post, informative version numbering is straightforward. Every version of software should be go through alpha, beta and release versions, for each change. When starting to edit the source code, increment the version number first. The number to increment, whether .., is determined by kind of compatibility the change will discard from the previous version: major=GUI/features, minor = data formats / APIs, build/patch = bugfixes. Once the number is first incremented, it is an ALPHA version, for testing/revision within the group (even of one person) that has developed it (any designers or programmers). Once alpha testing is complete within the developer group, whose preconceptions influence their testing, it is a BETA version, for testing outside of the developer group (customers, end users, random taste tests). Once beta testing/revision is complete, when all revision is complete, it is a RELEASE version, for another round of idiot-check retesting, usually by the release team testing with the packaging and distribution tools, with marketdroids given a more serious voice, when they take responsibility for unleashing it on the market. When alpha, beta or release phase revisions change compatibility with the previous version's GUI/features or data formats / APIs, the major or minor version number, respectively, is incremented, and it goes back to alpha testing. So an app might have version numbering like:
2.3 (released) -> 2.3.1a -> 2.3.1b -> 2.3.1 (released) -> 2.4a -> 2.4.b -> 2.4.1a -> 2.4.2a -> 2.4.3a -> 2.4.3b -> 2.4.4a -> 2.4.5a -> 2.4.5b -> 2.4.5 (released)
The versions released would be known only as 2.3, 2.3.1, and 2.4.5. 2.3 would be binary compatible with 2.3.1, and the same GUI and features, but 2.4.5 would only look and feel like 2.3, without binary compatibility (either data formats or APIs). This scheme makes version numbers actually useful, to consumers, new developers, and even automated interoperability systems (a la apt-get). It also offers an incentive to keep version numbers lower, as higher numbers reflect more changes (get it right the first time). At least in the minor and build/patch numbers. Most importantly, it reflects a reasonable test/revise/release discipline. So the numbers are the tail, wagged by the dog.
--
make install -not war