Skip to content

Commit

Permalink
Merge pull request #230 from nautobot/develop
Browse files Browse the repository at this point in the history
v2.0.1
  • Loading branch information
smk4664 authored Aug 8, 2023
2 parents 7710ba4 + 0ec90b9 commit 48da686
Show file tree
Hide file tree
Showing 4 changed files with 46 additions and 39 deletions.
2 changes: 1 addition & 1 deletion .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -104,7 +104,7 @@ jobs:
fail-fast: true
matrix:
python-version: ["3.8", "3.9", "3.10"]
nautobot-version: ["1.5.4", "latest"]
nautobot-version: ["1.5.4", "stable"]
runs-on: "ubuntu-20.04"
env:
INVOKE_NAUTOBOT_CHATOPS_PYTHON_VER: "${{ matrix.python-version }}"
Expand Down
7 changes: 7 additions & 0 deletions docs/admin/release_notes/version_2.0.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,13 @@
# v2.0 Release Notes

<!-- towncrier release notes start -->
## [v2.0.1 (2023-08-08)](https://github.com/nautobot/nautobot-plugin-chatops/releases/tag/v2.0.1)

### Changed

- [#228](https://github.com/nautobot/nautobot-plugin-chatops/issues/228) - Move Contributing Changelog Fragments higher in documentation


## [v2.0.0 (2023-08-02)](https://github.com/nautobot/nautobot-plugin-chatops/releases/tag/v2.0.0)

### Added
Expand Down
74 changes: 37 additions & 37 deletions docs/dev/contributing.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,35 @@ The project is following Network to Code software development guidelines and is
Documentation is built using [mkdocs](https://www.mkdocs.org/).
The [Docker based development environment](dev_environment.md#docker-development-environment) automatically starts a container hosting a live version of the documentation website on [http://localhost:8001](http://localhost:8001) that auto-refreshes when you make any changes to your local files.

## Creating Changelog Fragments

All pull requests to `next` or `develop` must include a changelog fragment file in the `./changes` directory. To create a fragment, use your GitHub issue number and fragment type as the filename. For example, `2362.added`. Valid fragment types are `added`, `changed`, `deprecated`, `fixed`, `removed`, and `security`. The change summary is added to the file in plain text. Change summaries should be complete sentences, starting with a capital letter and ending with a period, and be in past tense. Each line of the change fragment will generate a single change entry in the release notes. Use multiple lines in the same file if your change needs to generate multiple release notes in the same category. If the change needs to create multiple entries in separate categories, create multiple files.

!!! example

**Wrong**
```plaintext title="changes/1234.fixed"
fix critical bug in documentation
```

**Right**
```plaintext title="changes/1234.fixed"
Fixed critical bug in documentation.
```

!!! example "Multiple Entry Example"

This will generate 2 entries in the `fixed` category and one entry in the `changed` category.

```plaintext title="changes/1234.fixed"
Fixed critical bug in documentation.
Fixed release notes generation.
```

```plaintext title="changes/1234.changed"
Changed release notes generation.
```

## Adding a new top-level command

First, you should be familiar with the design goals and constraints involved in Nautobot (`design.md`).
Expand Down Expand Up @@ -143,50 +172,21 @@ You shouldn't need to make any changes to the `workers` module in this scenario.

- All code submissions should meet the following criteria (CI will enforce
these checks):
- Python syntax is valid
- All unit tests pass successfully
- PEP 8 compliance is enforced, with the exception that lines may be
- Python syntax is valid
- All unit tests pass successfully
- PEP 8 compliance is enforced, with the exception that lines may be
greater than 80 characters in length
- At least one [changelog fragment](#creating-changelog-fragments) has
- At least one [changelog fragment](#creating-changelog-fragments) has
been included in the feature branch

### Creating Changelog Fragments

All pull requests to `next` or `develop` must include a changelog fragment file in the `./changes` directory. To create a fragment, use your GitHub issue number and fragment type as the filename. For example, `2362.added`. Valid fragment types are `added`, `changed`, `deprecated`, `fixed`, `removed`, and `security`. The change summary is added to the file in plain text. Change summaries should be complete sentences, starting with a capital letter and ending with a period, and be in past tense. Each line of the change fragment will generate a single change entry in the release notes. Use multiple lines in the same file if your change needs to generate multiple release notes in the same category. If the change needs to create multiple entries in separate categories, create multiple files.

!!! example

**Wrong**
```plaintext title="changes/1234.fixed"
fix critical bug in documentation
```

**Right**
```plaintext title="changes/1234.fixed"
Fixed critical bug in documentation.
```

!!! example "Multiple Entry Example"

This will generate 2 entries in the `fixed` category and one entry in the `changed` category.

```plaintext title="changes/1234.fixed"
Fixed critical bug in documentation.
Fixed release notes generation.
```

```plaintext title="changes/1234.changed"
Changed release notes generation.
```

## Branching Policy

The branching policy includes the following tenets:

* The `develop` branch is the primary branch to develop off of.
* PRs intended to add new features should be sourced from the `develop` branch.
* PRs intended to address bug fixes and security patches should be sourced from the `develop` branch.
* PRs intended to add new features that break backward compatibility should be discussed before a PR is created.
- The `develop` branch is the primary branch to develop off of.
- PRs intended to add new features should be sourced from the `develop` branch.
- PRs intended to address bug fixes and security patches should be sourced from the `develop` branch.
- PRs intended to add new features that break backward compatibility should be discussed before a PR is created.

Nautobot ChatOps app will observe semantic versioning, as of 1.0. This may result in a quick turn around in minor versions to keep pace with an ever-growing feature set.

Expand Down
2 changes: 1 addition & 1 deletion pyproject.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[tool.poetry]
name = "nautobot-chatops"
version = "2.0.0"
version = "2.0.1"
description = "A plugin providing chatbot capabilities for Nautobot"
authors = ["Network to Code, LLC <opensource@networktocode.com>"]
readme = "README.md"
Expand Down

0 comments on commit 48da686

Please sign in to comment.