2010/2/15 Cornelius Hald <h...@icandy.de>: > The question is, whether or not we want that. If we release a library, we > will have to deal with API compatibility in successive versions, etc.
I think it would be helpful to create/ship a library. If we don't want to create a shared library just yet, we can always create a static library + some "compatibility level" C macros to issue compiler errors when the API changes (HE_ASSUME_API_LEVEL(1)?) against which packages link against (and depend on the -dev package). Any API changes could then be documented on the webpage or the wiki, with help and code examples on how to "upgrade" to a newer API version to make it easier for developers to upgrade to a new hildon-extras API version. Of course, this means that application packages that are not updated might not build from source in the future (source packages can be easily changed to the new API version; due to the static library, binary packages will not break). Even a static library seems to be a better solution than copy'n'paste. I believe that if users of hildon-extras (developers using HE in their projects) start to copy'n'paste stuff, they might add new features and fixes only in their local version, making it a nightmare for the HE maintainers to go and "collect" all fixes from different projects and merge them into the hildon-extras repository (it's also tedious merging changes from HE to the local copy). A compiler error pointing to a Wiki page that describes how to upgrade to a newer API version seems much more developer-friendly and allows us to improve things without requiring to commit to a fixed API too early. After some months when the bugs and API annoyance are ironed out, we can create a shared library and provide API/ABI compatibility. Please point out any thought errors that I might have had here ;) Thomas _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
