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 better. 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 http://www.pmacct.net/#mailinglists
