On 09/15/2010 05:48:51 AM, Paolo Lucente wrote:
> Hi Chris,
>
> On Tue, Sep 14, 2010 at 09:16:37AM +0200, Chris Wilson wrote:
>
> > I'm not sure about adding a new config switch, do we actually need
> it? I
> > seem to recall some wiser counsel to not add configuration options
> where
> > possible, as it exponentially multiplies the complexity of the
> software
> > code and also linearly increases the complexity of using it.
> >
> > If our intention is to rename the MySQL fields going forward, why
> not just
> > use a new schema version to grandfather the old column names?
>
> Funnily enough, and that was my perspective, in this case a
> configuration
> switch only adds two if-then-else in the common SQL plugins code.
> Whereas
> impact of a new schema version you can verify it yourself by grepping
> the
> source code for 'sql_table_version'. But saving a config switch, i
> agree,
> it's always nice. I'd target release 0.12.5 for this as 0.12.4 is
> planned
> to be out soon (by end of the month). Will give a shout as soon as i
> get
> something workable in the CVS.
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. So, I have thoughts.
Mostly on version numbering schemes. Feel free to ignore
this. I've not given it a whole lot of thought
regards pmacct.
Breaking backwards compatibility is ok in software under
development, pre version 1.0. After that I like seeing
the major version number bumped when there's a backwards
incompatible change (e.g. 1.0 -> 2.0). The friendly way
to proceed is to announce the upcoming change and
introduce a flag to enable the new functionality, with
the default to be not-enabled. (--new-feature=off).
Eventually the default changes to --new-feature=on
and the major version number increments. The next
time the major version number increments the flag,
--new-feature, is dropped.
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.
So, I like the major.minor.bugfix version numbering
system, where major is incremented when the user
really needs to pay attention or things just won't
work.
Perhaps the schema version numbering system
could also use a policy, so as to be able
to distinguish changes that break backwards
compatibility?
Karl <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
