Moin moin
I have got an idea about the “merge”. Currently the plan is that Avo depends
on OpenBabel and other libs, Kalzium (KDE4) depends on libavogadro.
Technically, we are already late in the game, because the first freeze is
already behind us, but I think we could do it in time (some weeks left).
Still, I am sure we all agree that there might be some bigger changes soon
(soon as in “before spring 2008”) which might introduce ABI/API-breakage
problems. If possible I would like Kalzium not to depend on version X of
libavogadro but of any libavogadro which is installed. This impliies a
API/ABI-freeze soon.
There is one very simple solution which of course has other disadvantages: We
could have a local copy of libavogadro in Kalzium
(trunk/kdeedu/kalzium/libavogadro/). Marcus develops features/bugfixes there
and merges it with the “real” libavogadro from time to time. The official
fixes are also going to be merged if possible.
When KDE 4.1 becomes trunk and KDE 4.0 is in branches/KDE/4.0/ we will remove
libavogadro from trunk and use the real avogadro. Until that point of time
(several month in the future) the API/ABI of libavogardo should be not only
better but also more stable so that the problems are (mostly) gone.
In case libavogadro breaks API lets say in January 2008 that is no problem at
all because no Kalzium using it is released. The KDE4.0 Kalzium will ignore
the API-change, the KDE 4.1 one will adopt to it.
The disadvantage is of course the merging which consumes time. Also, we won’t
be able to merge every change.
Another possibility: Technically we could even merge everything and adopt
Kalzium to it… Then the libavogadro in Kalzium would be a 100% copy of the
real one… We just wouldn’t have care about API/ABI breakage.
In short: The only real problem I see is to depend on a released libavogadro
when you still change API/ABI. As I think you should be able to break
API/ABI the local copy, even if it is a 100% copy of libavogadro, might be a
good option for us…
Carsten