[pacman-dev] alpm_db_get_pkgcache and alpm_db_get_grpcache rename

Dan McGee dpmcgee at gmail.com
Mon Dec 29 18:28:35 EST 2008


On Mon, Dec 29, 2008 at 1:48 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Sat, Dec 27, 2008 at 9:14 PM, Sebastian Nowicki <sebnow at gmail.com> wrote:
>> On 27/12/2008, at 11:53 PM, Xavier wrote:
>>
>>> On Sat, Dec 27, 2008 at 3:46 PM, Sebastian Nowicki <sebnow at gmail.com>
>>> 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


More information about the pacman-dev mailing list