pynetbox v7.5.0 release (#687)

Author: arthanson

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @arthanson @jnovinger @bctiemann @jeremystretch

.github/ISSUE_TEMPLATE/bug_report.yaml

@@ -11,14 +11,14 @@ body:
     attributes:
       label: pynetbox version
       description: What version of pynetbox are you currently running?
-      placeholder: v7.4.1
+      placeholder: v7.5.0
     validations:
       required: true
   - type: input
     attributes:
       label: NetBox version
       description: What version of NetBox are you currently running?
-      placeholder: v4.0.8
+      placeholder: v4.3.1
     validations:
       required: true
   - type: dropdown

.github/workflows/py3.yml

@@ -13,7 +13,7 @@ jobs:
     strategy:
       matrix:
         python: ["3.10", "3.11", "3.12"]
-        netbox: ["4.0", "4.1", "4.2"]
+        netbox: ["4.1", "4.2", "4.3"]
 
     steps:
       - uses: actions/checkout@v4

README.md

@@ -9,6 +9,9 @@ Each pyNetBox Version listed below has been tested with its corresponding NetBox
 
 | NetBox Version | Plugin Version |
 |:--------------:|:--------------:|
+|      4.3       |     7.5.0      |
+|      4.2       |     7.5.0      |
+|      4.1       |     7.5.0      |
 |      4.0.6     |     7.4.1      |
 |      4.0.0     |     7.3.4      |
 |      3.7       |     7.3.0      |

docs/development/getting-started.rst

@@ -0,0 +1,90 @@
+Getting Started
+==============
+
+This guide will help you get started with development on pynetbox. It covers setting up your development environment and running tests.
+
+Development Environment
+---------------------
+
+1. Fork the pynetbox repository on GitHub
+2. Clone your fork locally
+3. Create a virtual environment and install development dependencies:
+
+.. code-block:: bash
+
+    python -m venv venv
+    source venv/bin/activate  # On Windows: venv\Scripts\activate
+    pip install -e ".[dev]"
+
+Running Tests
+------------
+
+pynetbox uses pytest for testing. The test suite includes both unit tests and integration tests.
+
+Unit Tests
+~~~~~~~~~
+
+To run the unit tests:
+
+.. code-block:: bash
+
+    pytest tests/unit
+
+Integration Tests
+~~~~~~~~~~~~~~~
+
+The integration tests require a running NetBox instance. The test suite uses pytest-docker to spin up NetBox instances in Docker containers.
+
+To run the integration tests:
+
+.. code-block:: bash
+
+    pytest tests/integration
+
+You can specify which versions of NetBox to test against using the `--netbox-versions` flag:
+
+.. code-block:: bash
+
+    pytest tests/integration --netbox-versions 4.1 4.2 4.3
+
+Running Specific Tests
+~~~~~~~~~~~~~~~~~~~~
+
+You can run specific test files or test functions:
+
+.. code-block:: bash
+
+    # Run a specific test file
+    pytest tests/unit/test_api.py
+
+    # Run a specific test function
+    pytest tests/unit/test_api.py::test_api_status
+
+    # Run tests matching a pattern
+    pytest -k "test_api"
+
+Test Coverage
+~~~~~~~~~~~
+
+To run tests with coverage reporting:
+
+.. code-block:: bash
+
+    pytest --cov=pynetbox tests/
+
+Submitting Pull Requests
+----------------------
+
+Once you're happy with your work and have verified that all tests pass, commit your changes and push it upstream to your fork. Always provide descriptive (but not excessively verbose) commit messages. Be sure to prefix your commit message with the word "Fixes" or "Closes" and the relevant issue number (with a hash mark). This tells GitHub to automatically close the referenced issue once the commit has been merged.
+
+.. code-block:: bash
+
+    git commit -m "Closes #1234: Add IPv5 support"
+    git push origin
+
+Once your fork has the new commit, submit a pull request to the pynetbox repo to propose the changes. Be sure to provide a detailed accounting of the changes being made and the reasons for doing so.
+
+Once submitted, a maintainer will review your pull request and either merge it or request changes. If changes are needed, you can make them via new commits to your fork: The pull request will update automatically.
+
+.. warning::
+   Remember, pull requests are permitted only for **accepted** issues. If an issue you want to work on hasn't been approved by a maintainer yet, it's best to avoid risking your time and effort on a change that might not be accepted. (The one exception to this is trivial changes to the documentation or other non-critical resources.) 

docs/development/index.rst

@@ -0,0 +1,58 @@
+Development
+===========
+
+Thanks for your interest in contributing to pynetbox! This introduction covers a few important things to know before you get started.
+
+The Code
+--------
+
+pynetbox is maintained on GitHub. GitHub also serves as one of our primary discussion forums. While all the code and discussion is publicly accessible, you'll need to register for a free GitHub account to engage in participation. Most people begin by forking the pynetbox repository under their own GitHub account to begin working on the code.
+
+There are two permanent branches in the repository:
+
+* `master` - Active development for the upcoming patch release. Pull requests will typically be based on this branch unless they introduce breaking changes that must be deferred until the next major release.
+* `feature` - New feature work to be introduced in the next major release.
+
+pynetbox components are arranged into modules:
+
+* `core/` - Core functionality including API interaction, response handling, and query building
+* `models/` - Model definitions for different NetBox object types
+* `tests/` - Test suite including unit and integration tests
+* `docs/` - Documentation files
+
+Proposing Changes
+---------------
+
+All substantial changes made to the code base are tracked using GitHub issues. Feature requests, bug reports, and similar proposals must all be filed as issues and approved by a maintainer before work begins. This ensures that all changes to the code base are properly documented for future reference.
+
+To submit a new feature request or bug report for pynetbox, select and complete the appropriate issue template. Once your issue has been approved, you're welcome to submit a pull request containing your proposed changes.
+
+.. note::
+   Avoid starting work on a proposal before it has been accepted. Not all proposed changes will be accepted, and we'd hate for you to waste time working on code that might not make it into the project.
+
+Getting Help
+-----------
+
+There are two primary forums for getting assistance with pynetbox development:
+
+* GitHub discussions - The preferred forum for general discussion and support issues. Ideal for shaping a feature requests prior to submitting an issue.
+* #netbox on NetDev Community Slack - Good for quick chats. Avoid any discussion that might need to be referenced later on, as the chat history is not retained indefinitely.
+
+.. note::
+   Don't use GitHub issues to ask for help: These are reserved for proposed code changes only.
+
+Governance
+---------
+
+pynetbox follows the benevolent dictator model of governance, with the lead maintainer ultimately responsible for all changes to the code base. While community contributions are welcomed and encouraged, the lead maintainer's primary role is to ensure the project's long-term maintainability and continued focus on its primary functions.
+
+Licensing
+--------
+
+The entire pynetbox project is licensed as open source under the Apache 2.0 license. This is a very permissive license which allows unlimited redistribution of all code within the project. Note that all submissions to the project are subject to the same license.
+
+.. toctree::
+   :maxdepth: 2
+
+   getting-started
+   release-checklist 

docs/development/release-checklist.rst

@@ -0,0 +1,54 @@
+Release Checklist
+===============
+
+This document outlines the steps required to prepare and publish a new release of pynetbox.
+
+Pre-Release Tasks
+---------------
+
+1. Ensure all tests are passing:
+
+   .. code-block:: bash
+
+       pytest
+
+2. Update version number in `pynetbox/__init__.py`
+3. Update documentation for any new features or changes
+4. Check NetBox Docker releases:
+   - Visit https://github.com/netbox-community/netbox-docker/releases
+   - Review the latest NetBox Docker releases and their corresponding NetBox versions
+   - Update supported NetBox versions in `tests/integration/conftest.py` if needed
+   - Ensure the `get_netbox_docker_version_tag` function in `tests/integration/conftest.py` is updated with any new version mappings
+
+Release Tasks
+-----------
+
+1. Create a new release branch from `master`:
+
+   .. code-block:: bash
+
+       git checkout master
+       git pull
+       git checkout -b release/vX.Y.Z
+
+2. Commit version and changelog updates:
+
+   .. code-block:: bash
+
+       git commit -m "Prepare release vX.Y.Z"
+
+3. Create a pull request to merge the release branch into `master`
+4. Once merged, use github to create a new release:
+   - Go to the GitHub repository
+   - Click "Releases" in the right sidebar
+   - Click "Create a new release"
+   - Create a new tag (e.g., vX.Y.Z)
+   - Use the changelog content as the release description
+   - Publish the release
+
+   The GitHub release will automatically trigger the workflow to publish to PyPI.
+
+Supported NetBox Versions
+----------------------
+
+pynetbox aims to support the current and previous two minor versions of NetBox. The supported versions are defined in `tests/integration/conftest.py` and should be updated as part of the release process. 

docs/index.rst

@@ -8,6 +8,7 @@
    IPAM
    branching
    advanced
+   development/index
 
 TL;DR
 =====

pynetbox/__init__.py

@@ -1,4 +1,4 @@
 from pynetbox.core.api import Api as api
 from pynetbox.core.query import AllocationError, ContentError, RequestError
 
-__version__ = "7.4.1"
+__version__ = "7.5.0"

tests/conftest.py

@@ -3,7 +3,7 @@
 import pytest
 from packaging import version
 
-DEFAULT_NETBOX_VERSIONS = "4.2"
+DEFAULT_NETBOX_VERSIONS = "4.3"
 
 
 def pytest_addoption(parser):