Skip to content
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

Update various doc references to the main, develop, and next branches #1188

Merged
merged 1 commit into from Dec 23, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
21 changes: 10 additions & 11 deletions nautobot/docs/development/getting-started.md
Expand Up @@ -2,14 +2,13 @@

## Git Branches

The Nautobot project follows a branching model based on [Git-flow](https://nvie.com/posts/a-successful-git-branching-model/). As such, there are two persistent git branches:
The Nautobot project follows a branching model based on [Git-flow](https://nvie.com/posts/a-successful-git-branching-model/). As such, there are three persistent git branches:

* `main` - Serves as a snapshot of the current stable release
* `develop` - All development on the upcoming stable release occurs here
* `develop` - All bug fixes and minor feature development on the upcoming stable release occurs here
* `next` - All major new feature development for the next feature release occurs here.

At any given time, there may additionally be zero or more long-lived branches of the form `develop-X.Y.Z`, where `X.Y.Z` is a future stable release later than the one currently being worked on in the main `develop` branch.

You will always base pull requests off of the `develop` branch, or off of `develop-X.Y.Z` if you're working on a feature targeted for a later release. **Never** target pull requests into the `main` branch, which receives merges only from the `develop` branch.
You will always base pull requests off of either the `develop` branch, for fixes and minor features, or `next`, if you're working on a feature targeted for a later release. **Never** target fix or feature pull requests into the `main` branch, which receives merges only from the `develop` branch and only for new stable releases of Nautobot.

## Forking the Repo

Expand Down Expand Up @@ -78,9 +77,9 @@ You're now ready to proceed to the next steps.

### Creating a Branch

Before you make any changes, always create a new branch. In the majority of cases, you'll always want to create your branches from the `develop` branch.
Before you make any changes, always create a new branch. Again, for bug fixes and minor features, you'll want to create your branches from the `develop` branch, while for major new features, you'll branch from `next` instead.

Before you ever create a new branch, always checkout the `develop` branch and make sure you you've got the latest changes from `upstream`.
Before you ever create a new branch, always checkout the appropriate branch and make sure you you've got the latest changes from `upstream`:

```no-highlight
$ git checkout develop
Expand All @@ -90,10 +89,10 @@ $ git pull upstream develop
!!! warning
If you do not do this, you run the risk of having merge conflicts in your branch, and that's never fun to deal with. Trust us on this one.

Now that you've got the latest upstream changes, create your branch. It's convention to always prefix your branch name with your GitHub username, separated by hyphens. For example:
Now that you've got the latest upstream changes, create your branch. It's convention to always prefix your branch name with your GitHub username or your initials, and suffix it with the issue number if appropriate, separated by hyphens. For example:

```no-highlight
$ git checkout -b yourusername-myfeature
$ git checkout -b yourusername-myfeature-1234
```

## Enabling Pre-Commit Hooks
Expand Down Expand Up @@ -188,8 +187,8 @@ Additional useful commands for the development environment:

!!! note
If you are making edits to Nautobot's documentation in the Docker Compose workflow or otherwise needing to serve the docs locally, it is necessary to run a Python virtual environment:
- Follow the steps in the Nautobot docs to [install poetry](#install-poetry)

- Follow the steps in the Nautobot docs to [install poetry](#install-poetry)
- `poetry shell`
- `poetry install`
- `mkdocs serve`
Expand Down
10 changes: 5 additions & 5 deletions nautobot/docs/development/index.md
Expand Up @@ -100,7 +100,7 @@ The following documents the lifecycle of work within Nautobot.
a. Find an item that matches your request? Comment on the corresponding GitHub Issue or GitHub Discussion.
b. Don't see a match for your request? Continue.
3. Open a GitHub Issue
a. The issue will be reviewed. Based on the request, it will get labeled as `current`, `near-term`, `future`.
a. The issue will be reviewed. Based on the request, it will get labeled as `current`, `near-term`, `future`.
b. It will likely only stay in _current_ if it is trivial and quick work.
c. If it gets labeled as _future_, the issue will be closed in the next batch of issues that get migrated and converted to GitHub discussions.

Expand Down Expand Up @@ -236,9 +236,9 @@ invoke unittest --label nautobot.extras.tests.test_models.ConfigContextTest.test

- All new functionality must include relevant tests where applicable.

- When submitting a pull request, please be sure to work off of the `develop`
branch, rather than `main`. The `develop` branch is used for ongoing
development, while `main` is used for tagging stable releases.
- When submitting a pull request, please be sure to work off of the `develop` or `next`
branch as appropriate, rather than `main`. The `develop` branch is used for ongoing
fixes, and `next` is used for major new feature development, while `main` is used only for tagging stable releases.

- In most cases, it is not necessary to add a changelog entry: A maintainer will take care of this when the PR is merged. (This helps avoid merge conflicts
resulting from multiple PRs being submitted simultaneously.)
Expand All @@ -253,7 +253,7 @@ invoke unittest --label nautobot.extras.tests.test_models.ConfigContextTest.test

## Project Structure

All development of the current Nautobot release occurs in the `develop` branch; releases are packaged from the `main` branch. The `main` branch should _always_ represent the current stable release in its entirety, such that installing Nautobot by either downloading a packaged release or cloning the `main` branch provides the same code base.
All bug fixes and minor updates of the current Nautobot release occur in the `develop` branch; major feature development occurs in the `next` branch; and releases are packaged from the `main` branch. The `main` branch should _always_ represent the current stable release in its entirety, such that installing Nautobot by either downloading a packaged release or cloning the `main` branch provides the same code base.

Nautobot components are arranged into functional subsections called _apps_ (a carryover from Django vernacular). Each app holds the models, views, and templates relevant to a particular function:

Expand Down
4 changes: 0 additions & 4 deletions nautobot/docs/development/release-checklist.md
Expand Up @@ -71,10 +71,6 @@ Commit any necessary changes to the documentation before proceeding with the rel

Close the release milestone on GitHub after ensuring there are no remaining open issues associated with it.

### Merge the Release Branch

Submit a pull request to merge the `feature` branch into the `develop` branch in preparation for its release.

---

## All Releases
Expand Down