On 25 February 2010 00:50, Robert Ramey
Jarl Lindrud wrote:
The case we're referring to has come up due the presumption of a 32 bit version number. I made the version # with a certain expection of how it would be used - and it got used in a different way. And I failed to include extra code to enforce that expectation. When I added such code later, you got caught.
Was it a mistake on my part to not include such code until now? Maybe. Was it a mistake to not make this expectation explicit in the documentation. Maybe. Was it a mistake to presume that a version # would be able to hold upto 4 G versions? Maybe.
It would be nice if the version number could be more flexible. Currently for an SQL database, I use a major-minor versioning scheme for the schema. I have two version of the program in active use across multiple sites, all working with their own database... a "stable" version of a program, and a "beta" version. The Stable program uses (eg) database schema version 3.23 The Beta program uses (eg) database schema version 4.5 The Beta version was forked from Stable around db-schema-version 3.20, and then Stable was put on maintenance mode. At this point, Beta's schema version changed to 4.0 and it was modified as features were added. Stable required a few bug fixes, so 3.20 became 3.21, 3.22 etc. Two parallel versioning paths. 3.21 would've come at the time that Beta had already reached 4.3. 3.22 and 3.23 were released while Beta was on version 4.4, so later I released a Beta that could upgrade from 3.23 to 4.5 When the site upgrades to Beta, the Beta's upgrade system knows how to upgrade from the various stable versions. eg 3.20 --> 4.0, 4.1, 4.2, 4.3, 4.4, 4.5 3.21 --> 4.4, 4.5 3.22 --> 4.5 3.23 --> 4.5 This has worked well. It allows me to upgrade my schemas in parallel as required, and I don't have to shoe-horn it into a single-numbering scheme... which I guess would look something like this: 3.20 == version 50 51 52 etc version 4.0 == version 100 So now there is about 50 spare upgrade slots for Stable before I run out and hit where Beta began. This is an arbitrary limitation, I could've made it 10 slots and then really shot myself in the foot if I ended up needing 11. So could we look into freeing up the versioning scheme? It doesn't have to be a number... it just needs to be: a) put into a XML tag eg version="abc" b) portable in a binary sense c) support the < and == operator d) ?? is that it? with a bit of work, even compound versioning numbers like my major/minor are possible. what do you think? Paul