[Kde-extra-gear] Re: libkeg project.. thinking about

[Diego 'Flameeyes' Pettenò]

Waldo Bastian wrote:
> Just as with kdelibs, you will have to keep backwards compatibility in
> mind, that means that once it is released, you will need to provide
> backwards compatibility for quite some time to come. So you must be a bit
> careful what you put in there because it creates somewhat of a maintenance
> burden. For kdelibs we use the rule of thumb that we only put stuff in
> there that is used in at least 3 places, that we way we ensure that we
> don't end up with components that are actually only used in one place but
> because they are in kdelibs, have all kinds of compatibility restrictions
> on them.
> 
> With KEG the situation complicates a bit because there is no synchronized
> release cycle, so you when you release libkeg you must make sure that all
> parts of it are sufficient stable API wise so that you can ensure binary
> compatibility in the future.

I thought about this for some time, and I come out with a possible solution
(but at the moment is only a sketch, I was still thinking at it): all the
APIs released and documented remains in the library. If they should be
removed, they should be changed into a walk-through to accomplish the same
thing, and marked deprecated (there's a gcc extension which throws warnings
when a deprecated method is used, so a project which is using a deprecated
function will found it compiling the project itself, and if a project is
'dead' for some time (like was for knetload), any user which compiles it
will see the warnings, and someone will -probably- take some time to fix
them). After some time (3 months? 6 months? I think this should be decided
after we can se which lifecycle can have this library), the deprecated
methods are removed and a new minor version is released (we should set some
dates when the version is upgraded, so we can avoid to release two minor
version in two weeks :) ), if a project need an old API, links to the last
version with the previous minor number (maybe when we release a new minor
number we can release a 'compatibility' library with the include path which
has the version number in it, so two version of the library don't conflicts
one another).

Regards,
-- 
Diego "Flameeyes" Pettenò
dgp85 at users.sourceforge.net - http://flameeyes.web.ctonet.it/