Re: Maintenance of general implementations
On Feb 24, 1:59 am, fredrik.eriksson.storam...@gmail.com wrote:
I would like to know how big C++ systems manage their maintenance of
general implementations, such as Date-, Time-classes, queue handlers,
wrappers for transaction-system and so on. How to update and change
these implementations, to get a better quality, with minimal impact on
the applications that depends on these libs?
Where I work we have 100+ products that is driven in project form
which all depend on some set of general implementation. In practice we
can not change the binary dependency and signatures for the general
implementation and force these products to adapt.
Is there a best practice for this problem?
In many ways, you treat them exactly as you do any third party
libraries, or the compiler. Since you have control over them,
of course, you can do some things to make your life easier: for
example, any time you change the contract on the interface, you
change the signature, so that code expecting the old contract
won't compile.
Note that in some cases, this may entail keeping older versions
around, for the user code which hasn't yet adapted to the
change. (Clearcase is very good in managing this. From my
experience, other version control systems don't seem to be quite
at the same level, but this may just be that the places I've
worked which used them didn't know how to use them effectively.)
Also, of course, client code should statically link with them,
so you don't have the problem of different programs requiring
different versions of the same dynamic library.
I can only see two solutions:
1) We deliver different versions of these libs, and the products can
chose if they want to use the better quality libs and link against
these. There is about 3-10 libs that would be in different versions,
and about 30 header files, so I think that it would be doable to keep
track of the versions of these. Over time we can decrease the total
maintenance of the implementation and have better quality to a cheaper
price.
Keeping track of the versions, and which version each
application sees, is the job of your version control system. If
your version control system isn't doing it, easily, it's time to
learn it better, or change it, if it isn't possible.
2) We develop new classes and such concurrent to the old bad quality
implementation. This is, sort of, the way we are doing today. The
problem is still that if someone is using part of the implementation
we are in trouble if we want to change it. And the maintenance of the
implementation is increasing rapidly!
One possible solution is to include versionning information in
the namespace name. (I got this idea from Nathan Meyers, I
think.) But if the new class (or the class in the new
namespace) derives in fact from an older version, this should be
tracked in the version control system; you don't just start from
scratch.
And despite it all, one of the facts of life is that you will
occasionally have to do bug fixes in the older versions. Every
version control system I know allows branches, to support this,
but it does mean either merging, or applying the same fix to two
(or more) versions manually. It's extra work either way, but I
suspect that it's unavoidable.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]