Skip to content

Document Release Instructions #54

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Apr 6, 2021
Merged

Document Release Instructions #54

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
72ab79f
Add releasing instructions
rick-morrow Apr 1, 2021
4445224
Fix phrasing
rick-morrow Apr 1, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,3 +48,26 @@ it, you can serve it locally by following [these steps](https://docs.github.com/

NOTE: There can be a delay between changes going into the `master` branch and
GitHub Pages rebuilding with the changes.

## Releasing

The version checked into source is kept in an alpha state until we are ready to release. The release workflow automatically increments the version to a non-alpha version when a GitHub Release is created, and then moves to the next alpha afterwards.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we always have release branches ? I'm not sure, I haven't thought about this subject and how it should be handled.. I'm leaving it to @thejcannon to sort this out :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we not create a release branch later, if/when we needed one?


The release process is as follows:

1. Check the version located in [pyproject.toml](https://github.com/ni/python-styleguide/blob/main/pyproject.toml).
1. Create a [new release](https://github.com/ni/python-styleguide/releases/new) with the appropriate description.
1. Use the current version to specify the git tag. (remove the alpha part) (v1.0.0).
1. Publish the release.

Once this is released, it should show up on https://pypi.org/project/ni-python-styleguide/.

### Manually Setting Version

The Poetry verison can be manually overridden through `poetry version` commands. The version checked into source should be in an alpha state.

In a fork:

1. Run `poetry version preminor` for minor update (v0.1.7-alpha.0 -> v0.2.0-alpha.0).
1. Run `poetry version premajor` for major update (v0.6.7-alpha.0 -> v1.0.0-alpha.0).
1. Merge the fork and complete the normal release process above.