-
Notifications
You must be signed in to change notification settings - Fork 169
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proper lifecycle management for project #531
Comments
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. I'm interested to see all kinds of opinions about this, also how to get the 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: |
To add to my previous comment, for me personally at least, one of the slowing drivers for developing |
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 😁 |
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). |
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). Having said that I think the actual values are less important than just having a policy and communicating that! |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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:
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.
The text was updated successfully, but these errors were encountered: