Pynetbox version tied to NetBox version?

[markkuleinio]

(Oh we have discussions enabled here in pynetbox repo as well!)

What do you all think, would it be feasible to make pynetbox versions to work with specific NetBox versions only?

I mean, in the course of NetBox development there have been several cases where the API has been changed (quite appropriately, no problem there), which means that pynetbox needs to be made compatible with both earlier and current behaviour of NetBox API. That slows down adopting the new features in pynetbox (case: cable changes in NetBox 3.3 is a prime example).

Making pynetbox version X.Y.* only compatible with NetBox A.B API would make it easy to drop out support for legacy things and add new.

Obviously it would mean that the pynetbox user would need to pin the version and then manually test and change the new version when upgrading NetBox. But that's the case now in any case, this would just be made official.

I think some of the NetBox container repos also work in this way: a new version is released, with proper changes, whenever new NetBox version is released,

What do you all think?

[arthanson]

Good discussion, I'd add a couple points as I'm currently working on supporting NetBox 3.3.

The 3.3 changes will be breaking changes, so it won't be able to support older versions. I'm not sure historically if backwards compatibility has caused delays in releasing updates, but for the current NetBox 3.3 changes that is not what is causing the delays - it is a combination of switching maintainers and the 3.3 changes require some refactoring of the internals of the API to support things like a_terminations which return a mix of different types of objects (which the current pynetbox wasn't specifically designed to handle.

[markkuleinio]

Yeah, that's what I thought as well. I appreciate your efforts on this.

One idea I was thinking is (note I didn't say it is brilliant idea) creating "pynetbox2" fork that would have release versions synced with NetBox: "pynetbox2" versions 3.3.x would be compatible with NetBox 3.3 API, and so on. All the old compatibility code could be discarded, and patch versions could still be released as needed. Multiple branches would need to be maintained though, with some kind of cherry-picking I guess, when fixing bugs.

[markkuleinio]

After having some second thought, this "pynetbox2" idea is just plain bad. In strictest sense it would mean I was forced to upgrade all my apps at the same moment I was upgrading NetBox.

The current way is way better: I'll read the NetBox release notes, and decide which features I will specifically test (before upgrading the production instance). I can decide in every app (I have quite a many of them, not just one or two!) if I need to adjust them to support both the current NetBox and new NetBox (maybe by checking the API version at runtime), or if I can/need to upgrade pynetbox in the apps already before upgrading NetBox itself. Finally, after having NetBox upgraded, I can independently decide to drop the compatibility code or upgrade pynetbox in the apps.

The previously used policy in pynetbox (= add features in any release, drop features or change behaviour only in major release) provides more flexibility than having strong and continuing dependency between a pynetbox version and NetBox version.

[mtinberg]

Having pynetbox pin it's version support to a specific version of the Netbox API (matching version numbers can help make that easy) is what I was thinking too, but it does suggest that people using pynetbox need to pin the exact version of the API that their client app supports and is tested with. Breaking changes don't happen too often so you may not need to release for each minor revision, but the Release notes should maybe make clear which range of Netbox API version each pynetbox version works with, eg. if pynetbox 6.6 works with Netbox API 3.0-3.2 and pynetbox 6.7 works with 3.3-3.4 or whatever, people can pin to the right version and not accidentally upgrade to an incompatible one, or if they need to work with a 2.10.x API they know to install for example pynetbox 6.3 or something. People already need to upgrade client and server in lock step across breaking API changes, at least if they use the API which has changed.

I'm not sure how many parallel branches would need to be supported though because Netbox only releases on the current branch and sometimes n-1 so how often would you want to cherry pick a change and release for an API version that is no longer receiving changes? It seems that if someone is stuck on an old version of Netbox they want a matching old version of pynetbox too.

Maybe check the API version and print a compat warning when using pynetbox with a Netbox API that it isn't known to work with? Link to a github doc with a table of what pynetbox works with what netbox api and how to pin something with requirements.txt? So people who accidentally upgrade pynetbox across a breaking API boundary get some warning.

You can use compat code to make the supported version range wider, up until the point where the API exposes a difference that requires the client app to also change, which is probably often, in which case it's probably fine to require the client app to ask for a specific version to either keep the old API or move to a new one.

[markkuleinio]

I'm not sure how many parallel branches would need to be supported though because Netbox only releases on the current branch and sometimes n-1 so how often would you want to cherry pick a change and release for an API version that is no longer receiving changes?

I was thinking about the bugfixes in pynetbox: if there is a problem in for example handling plugins, it is a valid case for fixing it in the latest branch as well as in some other older branch(es). Naturally it can be selected to be left as an exercise for the user that is stuck (for some external reason) in older NetBox to patch the old pynetbox locally otherwise if the broken feature is needed.