Hi Neels,
On Mon, Oct 23, 2017 at 03:54:40AM +0200, Neels Hofmeyr wrote:
Ah, damn. I checked all of the repositories I know to use the VTY, I didn't imagine that OsmocomBB also has a VTY. That's really my fault then.
I think in general we should not fall into that trap. We have *no clue* at all who might be using libosmo* for whatever purpose. If we provide a libary with a given API/ABI, then it's our responsibility to keep that ABI/API as stable as possible.
I understand that it was hardly possible without fall-out in that particular case, and for sure there are exceptions.
However, completely unrelated to this particular topic (and hence the Cc to openbsc@) I'm not happy in general with the way how "carlessly" we sometimes introduce breakage. We have to be more disciplined in general on this. All of us.
BTW: The fact that this change has gone into master without being noticed also means that possibly we're not modelling osmocom-bb as a downstream user of libosmocore that needs to be rebuilt (and at least checked if it starts up correctly?) whenever testing a libosmocore change. That's also something to investigate. Maybe there's some way we can test this without too much effort.
Regards, Harald
On Mon, Oct 23, 2017 at 12:43:52PM +0200, Harald Welte wrote:
I think in general we should not fall into that trap. We have *no clue* at all who might be using libosmo* for whatever purpose. If we provide a libary with a given API/ABI, then it's our responsibility to keep that ABI/API as stable as possible.
True.
There are ways to fix this one: we can allow to register a given command a second time, which then replaces the previously registered command. We can also allow this only for the common node commands.
Should I implement this? Then upon new release, all potential VTY users out there can still register their own common node commands to replace the default ones and should not experience breakage.
~N
As a little side note: in future it's worth considering to make a release right before pushing significant changes which might result in user-visible breakage. It's easier to refer to version x.y.z than to git commit hash.
On 23.10.2017 16:24, Neels Hofmeyr wrote:
Then upon new release, all potential VTY users out there can still register their own common node commands to replace the default ones and should not experience breakage.