Hi Karl and all,

On Wed, 15 Sep 2010, Karl O. Pinc wrote:

> I too don't like having a config switch.  But note that changing the 
> schema in this fashion breaks backwards compatibility in anything that's 
> querying the data.

Agreed, I hadn't thought of that. Is this the first time that column has 
been renamed, removed or had its type changed in a schema version change?

> Breaking backwards compatibility is ok in software under
> development, pre version 1.0.

Isn't software always under development? In my view, the day it stops 
being in development, it's dead. And the user always has a choice to run 
the older version for as long as they think it serves their purposes 

That comment was almost a facile side note, but I think it's important for 
software to be able to break backwards compatibility, with care and and 
reason and planning, but not being able to do this results in the Win32 
API for example, and the millions of lines of mostly-unmaintained code 
that implements it.

> After that I like seeing the major version number bumped when there's a 
> backwards incompatible change (e.g. 1.0 -> 2.0).

There may be some merit to this, but I'm not sure that the work required 
to implement this is justified by what will hopefully be a once-only or 
very rare event (making a backwards-incompatible change to a schema).

> The friendly way to proceed is to announce the upcoming change and 
> introduce a flag to enable the new functionality,

The "flag" is already there: the sql_table_version in the config file.

> with the default to be not-enabled.  (--new-feature=off).

If you don't increase the sql_table_version number (in your own config 
file) by conscious effort, you keep the old structure.

> Eventually the default changes to --new-feature=on
> and the major version number increments.

The "default" for new installations, such as it is, has probably always 
been for the user to choose the most recent schema version, run the create 
scripts for it, and use it in their pmacctd.conf files.

> This is annoying to maintain but should give the end-user enough time to 
> make any changes that there should be no cause for complaint.

I think, in this case, users will have infinite time to update their 
databases if they wish, as we still support schema version 1.

Cheers, Chris.
Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

pmacct-discussion mailing list

Reply via email to