Re: [Boost-users] [serialization] class versioning changes in boost 1.42

Subject: Re: [Boost-users] [serialization] class versioning changes in boost 1.42
From: Paul (elegant_dice_at_[hidden])
Date: 2010-02-24 18:41:45

On 25 February 2010 00:50, Robert Ramey <ramey_at_[hidden]> wrote:
> 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