%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 [![Documentation Status](https://readthedocs.org/projects/autorelease/badge/?version=latest)](http://autorelease.readthedocs.io/en/latest/?badge=latest) [![Linux Build](https://travis-ci.org/dwhswenson/autorelease.svg?branch=master)](https://travis-ci.org/dwhswenson/autorelease) [![Windows Build](https://ci.appveyor.com/api/projects/status/ox0c6u5gobk5ksat/branch/master?svg=true)](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 [![Documentation Status](https://readthedocs.org/projects/autorelease/badge/?version=latest)](http://autorelease.readthedocs.io/en/latest/?badge=latest) [![Linux Build](https://travis-ci.org/dwhswenson/autorelease.svg?branch=master)](https://travis-ci.org/dwhswenson/autorelease) [![Windows Build](https://ci.appveyor.com/api/projects/status/ox0c6u5gobk5ksat/branch/master?svg=true)](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 [![Documentation Status](https://readthedocs.org/projects/autorelease/badge/?version=latest)](http://autorelease.readthedocs.io/en/latest/?badge=latest) [![Linux Build](https://travis-ci.org/dwhswenson/autorelease.svg?branch=master)](https://travis-ci.org/dwhswenson/autorelease) [![Windows Build](https://ci.appveyor.com/api/projects/status/ox0c6u5gobk5ksat/branch/master?svg=true)](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 - 0.4.0-1 - Package Spec generated