Example and practice area for python releases.
## 0: Have a python package
There are several python packages that need your help.
#### Register python project
`python setup.py register`
### 1: Accrue consensus for release
Use peer review, and pull requests to your advantage.
Set up a `dev` branch to prepare all releases. Create the first `dev` branch
immediately after the first release. Immediately create a pull request from
`dev` into `master`. Encourage people to create topical branches into the
`dev` branch. When the `dev` branch is ready to be merged into to the master
branch, this signals the developers belief that the code included should be
used by default which creates a new release.
Make sure to "bump" the [version number](http://semver.io/) to create the first
commit needed to create a pull request. In the initial development states,
ensure that the version number ends with the `-dev` label.
### 2: Release Dance
To create a new release of a python module, ensure the version number is
accurate according to http://semver.io/ in `setup.py`.
#### Merge to master
Merge the pull request either using the github merge button or using git on the
commandline from the `master` branch:
```
git checkout dev && git pull
git checkout master && git pull
git merge dev
```
At this point you have a git branch with everything needed for a release.
If using commandline instead of github pull request, ensure to close pull
request and delete `dev` branch on github.
#### Verify release
```
# Install locally as symlink
sudo python setup.py develop
# Install a copy as system package
sudo python setup.py install
# Should bring up a help page.
pydoc stdprojectexample
```
Run smoke tests.
Update changelog.
We're about to create new commits.
#### Tag Release
Semver says the version will be `x.y.z`. Ensure the version is accurate. Edit
the `setup.py` file to ensure that the `-dev` label is removed, commit results.
Repeat verification steps.
```
git tag x.y.z
```
Git tag will allow you to add notes, changelog is recommended, citation of pull
requests is encouraged.
#### Publish Results
Transfering your results over a network link beyond your computer is indelible
and irreversible. Any mistakes must be mitigated by another release. A
release is a bell that cannot be unrung.
##### Push to PyPi
```
# Upload to PyPi
python setup.py build sdist_egg upload
```
Observe new release in pypi.
##### Push to Github
Push `master` branch along with all tags to github.
```
git push origin --tags master
```
Observe new release in Github.
### 3: Post Release
```
git branch -d dev
git checkout -b dev
# edit setup.py
```
Edit `setup.py` to bump the version number; according to semver, this would be
a patch release without any deltas, by default.
```
git commit -avm "init new development area"
git push -u origin dev
```
Create a new pull request on Github.
## Congratulations
Go tweet about your new release.
To install: `pip install -U stdprojectexample`.
To install an arbitrary (eg `dev`) version using pip without cloning the repo:
```
pip install -U http+https://github.com/openaps/stdprojectexample.git@dev
```
Metadata
Release files for stdprojectexample 0.0.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| stdprojectexample-0.0.0-py2.7.egg | Legacy Egg format | - | - | Details for stdprojectexample-0.0.0-py2.7.egg |
Release files / stdprojectexample-0.0.0-py2.7.egg
| Download URL | stdprojectexample-0.0.0-py2.7.egg |
|---|---|
| Size | 3.3 kB |
| Tags | Egg |
|
SHA-256 checksum How to use checksums |
5461b78aefbd39fe1b6d83485cd1e968e3c2882ebc88e13d9a7489cebe7003b5
|
|
BLAKE2b-256 checksum How to use checksums |
6ce51597df22d35671c022693a0723d4009ba960c27d376bc08b1b5f5ff5aad3
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for stdprojectexample 0.0.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.