Proper lifecycle management for project

[bluikko]

Since #521 was merged without deprecation period it broke everyone's netbox.netbox.nb_lookup ansible module. To avoid a repeat of such occurrence I propose that:

• There could be proper lifecycle management for the features; deprecation notification in changelog and eventual removal in some future major version.
• Some coordination together with the project https://github.com/netbox-community/ansible_modules/ with regards to deprecation/removal and other breaking changes. These two projects even lives in the same GitHub namespace netbox-community!

The details could be discussed such as acceptable deprecation time and so on. I hope this issue could open discussion on how to avoid future breakage in the NetBox ecosystem.

[markkuleinio]

Yes, in ideal world everyone would read the deprecation notices of their most important dependencies (just like they read the release notes) and prepare their apps for a future change. NetBox dropped the private keys about 18 months ago. pynetbox 6.3.0 deprecated .all() for endpoints, for some reason it was missed when releasing 7.0.0 but the ansible modules still use it.

I'm interested to see all kinds of opinions about this, also how to get the pynetbox development up to speed again, there is already something in the discussion tab, as well as the new releases (thanks!).

Interesting data point was also seen in #511: quite large percentage of downloads were for older (pinned) versions so there was some kind of lifecycle management going on.

Let's introduce new package for every new NetBox major version: pynetbox35 is only compatible with NetBox 3.5 🤔😁 No risk for missing deprecations or making breaking changes.

[markkuleinio]

To add to my previous comment, for me personally at least, one of the slowing drivers for developing pynetbox is the burden of supporting old NetBox versions with non-compatible APIs. IMO that should be one important aspect to consider when planning the future development of pynetbox. Would it be possible to save the NetBox API version from each API response and use it for the next call? Is it feasible to maintain the codebase with the conditional styles? Each NetBox major release (every 4 months or so) is expected to have some changes in the API, that's what major releases are for (like pynetbox 6.x to 7.x). (Hence my quick comment about pynetbox35)

[markkuleinio]

Merging in #521 in 7.0.1 was unfortunate. I didn't really know when the next release (after 6.6.2) is coming and with what kind of codebase, so I sent the PR only after 7.0.0 was already released and it was announced that support for older NetBoxes was dropped. Maybe an alpha version or a release candidate could be released before major versions so that non-maintainers can better propose major changes? I believe merging major changes is also easier at that point (instead of sending a PR long time ahead of the next major release), I don't know. Or maybe I just wasn't able to track the commits or branches correctly 😁

[arthanson]

Those are good ideas @bluikko and @markkuleinio - There was a major change for 7 after there was a buildup of old issues / PRs and NetBox change, but agree there should be better lifecycle management. Will go over these and put some proposals up here (or in discussion).

[bluikko]

Speaking for myself only - and hoping some other users would share their views also: it would definitely be reasonable to limit which NetBox versions are supported. Especially when NetBox itself only updates the latest minor version and not even the n-1 minor version (with very rare exceptions). Given the API changes are common I could see users being stuck on the n-1 minor version for quite some time while preparing everything to update to the latest version.
So I think keeping compatibility only with the current minor + the previous minor would be reasonable.

Having said that I think the actual values are less important than just having a policy and communicating that!
Individual environments can always prepare for changes they're not yet ready by using PEP 440 as long as they know what to expect. And as @markkuleinio says having a pre-release version would help in that as well.