Le 18/11/2010 01:18, Lex Trotman a écrit :
On 18 November 2010 10:16, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 17/11/2010 23:09, Lex Trotman a écrit :
On 18 November 2010 03:36, Colomban Wendling lists.ban@herbesfolles.org wrote:
But does new API really matters? If a plugin writer wants to keep being compatible with old Geany versions, she just have not to use new API -- as far as the ABI hasn't changed.
But ATM how does a plugin check that without being re-compiled?
What what what? :D If a plugin compiles with version 0.18 and Geany doesn't detect a problem when comparing the ABI version it was built against, it IS compatible, no? And if the same plugin is compiled against Geany 0.19 (assuming the ABI hasn't changed), it will still work with Geany 0.18...
Yes, but ANY change to the API/ABI even in areas that the plugin doesn't use changes the version and makes the plugin incompatible with older Geany.
Okay, I think I got your point, reading this and some other mails in this thread: you want to prevent ABI bumps to break plugins that are not directly affected.
Yes, an ABI bump break every plugin that was compiled before it. If it isn't affected, it has to be rebuild.
But I'm with Enrico here: I don't think ABI bumps will/should happen often.
And finally, if you want to protect from ABI breakage, you have to protect every symbol, not only functions, but also structures and structure members (even enums values may need this then).
So... while I'm not (and never was) against having a very flexible dependency mechanism, I still think it's overkill, and won't it to make everything complicated. If backbard compatibility is this important, I'd prefer to simply keep the whole ABI stable, even if it may cost some deprecated things and some "old and now useless stuff": it isn't really nice either, but still seems less bloated to me.
But I'd be curious to see how you would implement this :)
Regards, Colomban