On Mon, Dec 29, 2008 at 1:48 PM, Aaron Griffin <[email protected]> wrote: > On Sat, Dec 27, 2008 at 9:14 PM, Sebastian Nowicki <[email protected]> wrote: >> On 27/12/2008, at 11:53 PM, Xavier wrote: >> >>> On Sat, Dec 27, 2008 at 3:46 PM, Sebastian Nowicki <[email protected]> >>> wrote: >>>> >>>> Hi, >>>> >>>> Recently the alpm_db_get_{pkg,grp}cache() functions were renamed to >>>> alpm_db_get_{pkg,grp}cache()[1]. Since this is a public API change, >>>> shouldn't the old functions perhaps simply be deprecated and "alias" the >>>> new >>>> functions, instead of dropping them completely? I'd imagine this would >>>> potentially break some front-ends if libalpm gets updated, as was the >>>> case >>>> with a project of mine. >>>> >>>> [1]: commit: d05882db9e417244fa580c4697b45333faffcc79 >>>> >>> >>> This will only appear in 3.3 which does not even have any clear >>> roadmap so which looks quite far away from now. >>> It won't be in the next 3.2.2 release. >> >> There would probably still need to be some transition stage. As long as you >> guys are aware of the potential problem, I don't really mind ;). > > If we stick a note in the ChangeLog, that's usually enough for most > projects. "API changed. Fix your crap". Lots of other projects do > that.
I've always stuck with the minor releases don't change the API, while major releases probably will. I also ensure our libtool version number incrementing happens, so you will have to rebuild anything that links against pacman anyway do to an SO number bump. This has happened before and will surely continue to happen, especially if we get a true transactional API anytime soon. -Dan _______________________________________________ pacman-dev mailing list [email protected] http://archlinux.org/mailman/listinfo/pacman-dev
