diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-autorelease.spec | 190 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 192 insertions, 0 deletions
@@ -0,0 +1 @@ +/autorelease-0.4.0.tar.gz diff --git a/python-autorelease.spec b/python-autorelease.spec new file mode 100644 index 0000000..b93ccb5 --- /dev/null +++ b/python-autorelease.spec @@ -0,0 +1,190 @@ +%global _empty_manifest_terminate_build 0 +Name: python-autorelease +Version: 0.4.0 +Release: 1 +Summary: Tools to keep the release process clean. +License: MIT +URL: https://github.com/dwhswenson/autorelease +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/9f/43/42451d942fec7bff15de925024d0b923c5fd83c5aec14f1d7900f732b65d/autorelease-0.4.0.tar.gz +BuildArch: noarch + +Requires: python3-packaging +Requires: python3-pyyaml +Requires: python3-gitpython +Requires: python3-future +Requires: python3-requests +Requires: python3-dateutil +Requires: python3-click + +%description +[](http://autorelease.readthedocs.io/en/latest/?badge=latest) +[](https://travis-ci.org/dwhswenson/autorelease) +[](https://ci.appveyor.com/project/dwhswenson/autorelease/branch/master) + +# Autorelease + +Release management for GitHub and continuous integration, based on branches. +The basic philosophy is to maintain development branches (which always have +development versions of the code) and release branches (which always have +release versions of the code). The workflow for a release is therefore: + +1. Update the version for release and make a PR to a stable branch; the top + post will be the release notes. +2. Merge the PR. + +That's it. Autorelease handles the rest. + +When you make the PR to a stable branch, Autorelease will deploy the package to +testpypi, and re-download it and test it again. This ensures that you don't +publish broken packages. After you merge to the stable branch, Autorelease will +cut a new release on GitHub, and then publish the release on PyPI. + +Tools included: + +* Travis config imports and scripts to automatically test-deploy on testpypi, + then cut a GitHub release, then deploy to PyPI. +* Vendor-able GitHub Actions workflows for test-deploy, GitHub release, and +PyPI deploy. +* Vendor-able `version.py` that gives one true location for version + (`setup.cfg`) while also enabling developer installs to give full and correct + version information. +* Vendor-able `setup.py` that keeps all user-required information in the + `setup.cfg`. +* Script to draft release notes based on labels on merged PRs. + +If you're a Python developer who uses Travis and GitHub, Autorelease handles +everything related to releasing to PyPI. + + +%package -n python3-autorelease +Summary: Tools to keep the release process clean. +Provides: python-autorelease +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-autorelease +[](http://autorelease.readthedocs.io/en/latest/?badge=latest) +[](https://travis-ci.org/dwhswenson/autorelease) +[](https://ci.appveyor.com/project/dwhswenson/autorelease/branch/master) + +# Autorelease + +Release management for GitHub and continuous integration, based on branches. +The basic philosophy is to maintain development branches (which always have +development versions of the code) and release branches (which always have +release versions of the code). The workflow for a release is therefore: + +1. Update the version for release and make a PR to a stable branch; the top + post will be the release notes. +2. Merge the PR. + +That's it. Autorelease handles the rest. + +When you make the PR to a stable branch, Autorelease will deploy the package to +testpypi, and re-download it and test it again. This ensures that you don't +publish broken packages. After you merge to the stable branch, Autorelease will +cut a new release on GitHub, and then publish the release on PyPI. + +Tools included: + +* Travis config imports and scripts to automatically test-deploy on testpypi, + then cut a GitHub release, then deploy to PyPI. +* Vendor-able GitHub Actions workflows for test-deploy, GitHub release, and +PyPI deploy. +* Vendor-able `version.py` that gives one true location for version + (`setup.cfg`) while also enabling developer installs to give full and correct + version information. +* Vendor-able `setup.py` that keeps all user-required information in the + `setup.cfg`. +* Script to draft release notes based on labels on merged PRs. + +If you're a Python developer who uses Travis and GitHub, Autorelease handles +everything related to releasing to PyPI. + + +%package help +Summary: Development documents and examples for autorelease +Provides: python3-autorelease-doc +%description help +[](http://autorelease.readthedocs.io/en/latest/?badge=latest) +[](https://travis-ci.org/dwhswenson/autorelease) +[](https://ci.appveyor.com/project/dwhswenson/autorelease/branch/master) + +# Autorelease + +Release management for GitHub and continuous integration, based on branches. +The basic philosophy is to maintain development branches (which always have +development versions of the code) and release branches (which always have +release versions of the code). The workflow for a release is therefore: + +1. Update the version for release and make a PR to a stable branch; the top + post will be the release notes. +2. Merge the PR. + +That's it. Autorelease handles the rest. + +When you make the PR to a stable branch, Autorelease will deploy the package to +testpypi, and re-download it and test it again. This ensures that you don't +publish broken packages. After you merge to the stable branch, Autorelease will +cut a new release on GitHub, and then publish the release on PyPI. + +Tools included: + +* Travis config imports and scripts to automatically test-deploy on testpypi, + then cut a GitHub release, then deploy to PyPI. +* Vendor-able GitHub Actions workflows for test-deploy, GitHub release, and +PyPI deploy. +* Vendor-able `version.py` that gives one true location for version + (`setup.cfg`) while also enabling developer installs to give full and correct + version information. +* Vendor-able `setup.py` that keeps all user-required information in the + `setup.cfg`. +* Script to draft release notes based on labels on merged PRs. + +If you're a Python developer who uses Travis and GitHub, Autorelease handles +everything related to releasing to PyPI. + + +%prep +%autosetup -n autorelease-0.4.0 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-autorelease -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Wed May 10 2023 Python_Bot <Python_Bot@openeuler.org> - 0.4.0-1 +- Package Spec generated @@ -0,0 +1 @@ +89fbb8b1ff3f9ce88d49aca8d2ef6ef3 autorelease-0.4.0.tar.gz |