[pacman-dev] alpm_db_get_pkgcache and alpm_db_get_grpcache rename
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
On Sat, Dec 27, 2008 at 3:46 PM, Sebastian Nowicki <sebnow@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.
On 27/12/2008, at 11:53 PM, Xavier wrote:
On Sat, Dec 27, 2008 at 3:46 PM, Sebastian Nowicki <sebnow@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 ;).
On Sat, Dec 27, 2008 at 9:14 PM, Sebastian Nowicki <sebnow@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@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.
On Mon, Dec 29, 2008 at 1:48 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Sat, Dec 27, 2008 at 9:14 PM, Sebastian Nowicki <sebnow@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@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
On 30/12/2008, at 4:48 AM, Aaron Griffin wrote:
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.
Indeed, it's no biggy, even a global sed would fix it :) On 30/12/2008, at 8:28 AM, Dan McGee wrote:
This has happened before and will surely continue to happen, especially if we get a true transactional API anytime soon.
-Dan
Looking forward to it.
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Sebastian Nowicki
-
Xavier