| |
@@ -210,3 +210,37 @@
|
| |
Unlike the regular test environment, this environment also implicitly runs
|
| |
`fedmod fetch-metadata` in order to ensure that the metadata fetching operation
|
| |
also works correctly given only system packages as dependencies.
|
| |
+
|
| |
+ ## Publishing new releases
|
| |
+
|
| |
+ ### COPR releases
|
| |
+
|
| |
+ The main current release mechanism is through COPR at
|
| |
+ https://copr.fedorainfracloud.org/coprs/g/modularity/fedmod/.
|
| |
+
|
| |
+ This is configured to automatically build a new release every time a new tag
|
| |
+ is pushed to the `fedmod` git repository.
|
| |
+
|
| |
+ `fedmod`'s RPMs are built with `tito`, but version tagging is handled with a
|
| |
+ helper script. To publish a new release, run:
|
| |
+
|
| |
+ $ ./tag-release.sh <X.Y.Z>
|
| |
+ $ git push && git push --tags
|
| |
+
|
| |
+
|
| |
+ ### PyPI releases
|
| |
+
|
| |
+ `fedmod` is also published to PyPI here: https://pypi.org/project/fedmod/
|
| |
+
|
| |
+ After releasing to COPR to ensure everything is properly tagged, a new PyPI
|
| |
+ release can be made by doing:
|
| |
+
|
| |
+ $ cd src
|
| |
+ $ rm dist/*
|
| |
+ $ python setup.py sdist bdist_wheel
|
| |
+ $ twine upload dist/*
|
| |
+
|
| |
+ The `dnf` and `solv` dependencies unfortunately mean the PyPI release isn't
|
| |
+ particularly useful at this point (`pipsi` doesn't allow system level
|
| |
+ dependencies, and even if it did, platforms that provide these libraries are
|
| |
+ also likely to provide access to COPR).
|
| |
