3. Changes¶
- . contents:: Releases
local:
3.1. TODOs¶
Parse
git describe
like setuptools_scm plugin does.Drop pvcmd/pvtags.py, and replace it with polyversion?
Engravings: Not easy to extend!
Configurable hooks - refactor engravings as one of them. to run, for example, housekeeping commands on all subprojects like
pip install -e <project>
and immediately start working in “develop mode”.This would allow housekeeping commands and validate tests before/after every bump:
## Pre-release hook # pytest tests ## Post-release hook # rm -r dist/* build/*; python setup.py sdist bdist_wheel twine upload dist/*whl -s
Add top-level engrave glob-excludes.
Use astor grafter.
Refactor version-bump algebra to support a single modifier per segment (see
multivermath
branch).Lock release-trains as “alpha/beta”.., specific branches can be selected Based on version-bump algebra), this will force users to always use
pip install --pre
to fetch such release-trains. This is a safeguard to avoid accidentally landing half-baked code to users.Retrofit polyversion library as a plugin of polyvers command.
Function as plugin for other 3rd-party projects, bake a cookiecutter
Check what happens with no-commit, e.g. to temporarily package a wheel.
3.2. 2018-08-07: polyversion-v0.2.2a1, polyvers-v0.1.1a1¶
Maintenance release.
- enh: polyversion now logs which was cmd not found on Windows
(usually it is executing
git
). - chore: Merge all pyupd requests for dependencies.
3.3. 2018-07-08: polyversion-v0.2.2a0¶
FIX: git < 2.15.0 was buggy with multiple match-patterns in command:
git describe --match=... --match=...
(see https://github.com/git/git/blob/master/Documentation/RelNotes/2.15.0.txt)
The
polyvers
cmd still affected by this.
3.4. 2018-07-06: polyvers-v0.1.1a0¶
FIX: engravings were applied unsorted (based on their start-point) and offsets were miss-located when switching graft in a same file.
3.5. 2018-07-05: polyversion-v0.2.1a0¶
- Feature: The
POLYVERSION_LOG_LEVEL
control polyversion verbosity. Runpolyversion -h
fo help. - Change: minor reordering when searching version from package-metadata.
- fix: add standalone
bin/pvlib.run
from last release. - fix:
polyversion()
/polytime()
are guessingbasepath
keyword from the path of caller’s top-package (not just from caller’s fpath).
3.6. 2018-07-04: polyversion-v0.2.0a2¶
- Version v0.2.0a0 not in pypi, consumed for standalone
bin/pvlib.run
. - Version v0.2.0a1 were not finding sbling-dir versions if
pip install git+...
, and had not replaced all skip-bdist flags.
3.6.1. Features¶
- Teach non-engraved projects how to retrieve polyversion when pip-installed:
- The functions
polyversion()
&polytime()
now attempt to fetch version from package/site-package infos. - And the function doing this
polyversion.pkg_metadata_version()
retrofitted to:- search for <pname-<version>.egg-info/PKG-INFO in baspath sibling folder (before searching PKG-INFO, METADATA in basepath),
- so now basepath always needed in
polyversion()/polytime()
functions to locate sibling dir.
- The functions
3.6.2. Breaking Changes¶
- Rename setuptools flag from
skip_polyversion_check --> polyversion_check_bdist_enabled
to flip its default logic (not checking by default), since non-engraved wheels install just fine now. - Rename the keyword of
polyversion()
/polytime()
functions fromrepo_path --> basepath
to denote its importance for retrieving the version of installed projects from sibling dirs insidePYTHONPATH/site-packages/
.
3.7. 2018-06-29: polyversion-v0.1.1a3¶
(change actually done in v0.1.1a1, just a fixes & doc-msg in a2)
- FIX: teach setuptools plugin about default version env-var.
Now can
pip install git+https://some.git.repo/but-from/non-engraved-branch
.
3.8. 2018-06-27: polyversion-v0.1.1a0¶
- FEAT: Introduce configurable default version env-var to fall-back
to
<pname>_VERSION
if it exists, in case of errors (e.g. no git). The presence of such a variable also setspolytime(no_raise=True)
, which now also support thepname
anddefault_version_env_var
kwds.
3.9. 2018-06-06: polyvers-v0.1.0a1, polyversion-v0.1.0a7¶
Mostly docs, combined release.
- FEAT: reinstated engravings on
_version.py
(see previous release for rational).
3.10. 2018-06-05: polyvers-v0.1.0a0, polyversion-v0.1.0a6: co2mpas-ready¶
- FEAT: reinstated engravings on
setup.py
(dropped only for a while in 2018-06-03: polyversion-v0.1.0a3: setuptools ), since, assuming clients have adopted the new setuptools plugin keyword, it is the default_version that will be engraved, which is fine. - fix: report any version matched both from v-tags and r-tag’s.
- fix:
bump
command does not engrave egg-related files. polyversion
command got a bit more civilized (with logging to explain problems with related stacktraces.- dev: don’t test building wheel on travis…too much fuzzz.
3.11. 2018-06-05: polyversion-v0.1.0a5¶
- Disable standalone-wheel hack from
pvlib/setup.py
and rely on setuptools plugin even for polyversion ONCE MORE. (but no need to update standalone, which is a wheel, unaffected by that)
3.12. 2018-06-05: polyversion-v0.1.0a4¶
Bugfixing polyversion (and generate a non-buggy standalone wheel):
FIX polyversion where it ignored
setup(default_version
keyword. (6519a1ba)fix: polyversion stop eating half of its own dog food: cannot reliably use setuptools plugin for its installation. (56a894cde)
Monkeypatching distutils for bdist-check was failing in PY2 due to being an “old class”. (1f72baec)
doc: fixed recommendation about how to bypass bdist-check to this:
… You may bypass this check and create a package with non-engraved sources (although it might not work correctly) by adding skip_polyversion_check option in your
$CWD/setup.cfg
file, like this:[global] skip_polyversion_check = true ...
3.13. 2018-06-03: polyversion-v0.1.0a3: setuptools¶
v0.1.0a2`Canceled (like the previous 2), cannot release from r-tags because ``setup()` reports version from v-tag.
- Q: Is a new setup-keyword needed
--is-polyversion-release
? - A: no, just search both.
- Q: Is a new setup-keyword needed
v0.1.0a0 had been canceled for the same reason, but somewhere down the road, the fix was reverted (bdist-check works for r-tag only).
v0.1.0a1 just marked that our
setup.py
files ate our dog food.
3.13.1. Breaking changes¶
Dropped all positional-arguments from
polyversion.polyversion()
; was error-prone. They have all been converted to keyword-arguments.Renamed data in
polyversion
(also applied forpolyvers.pvproject.Project()
):pvtag_frmt --> pvtag_format vtag_frmt --> vtag_format
Changed arguments in
polyversion.polyversion()
(affect alsopolyvers.pvproject.Project()
):default --> default_version tag_frmt --> tag_format --> vprefixes (new) --> is_release (new)
REVERTED again the 0.0.2a9 default logic to raise when it version/time cannot be derived. Now by default it raises, unless default-version or
no_raise
forpolyversion.polytime()
.Stopped engraving
setup.py
files ; clients should use setuptools plugin to derive version for those files (see new features, below)). For reference, this is the removed element from defaultProject
’s configuration (in YAML):globs: [setup.py] grafts: - regex: -| (?xm) \bversion (\ *=\ *) .+?(, \ *[\n\r])+
polyversion library searches both v-tags and r-tags (unless limited). Previously, even checked-out on an r-tag, both
polyversion
command andpolyvers bump
would ignore it, and report +1 from the v-tag!
3.13.2. Features¶
The polyversion library function as a setuptools “plugin”, and adds two new
setup()
keywords for deriving subproject versions from PKG-INFO or git tags (seepolyversion.init_plugin_kw()
):- keyword:
polyversion --> (bool | dict)
When a dict, its keys roughly mimic those in
polyversion()
, and can be used like this:from setuptools import setup setup( project='myname', version='' # omit (or None) to abort if cannot auto-version polyversion={ # dict or bool 'mono_project': True, # false by default ... # See `polyversion.init_plugin_kw()` for more keys. }, setup_requires=[..., 'polyversion'], ... )
- keyword:
keyword:
skip_polyversion_check --> bool
When true, disable bdist-check, when false (default), any bdist_* (e.g.bdist_wheel
), commands will abort if not run from a release tag. You may bypass this check and create a package with non-engraved sources (although it might not work correctly) by invoking the setup-script from command-line like this:$ python setup.py bdist_wheel --skip-polyversion-check
- bump cmd: engrave also non-bumped projects with their
git describe
-derived version (controlled by
--BumpCmd.engrave_bumped_only
flag).
- bump cmd: engrave also non-bumped projects with their
Assign names to engraves & grafts for readable printouts, and for refering to them from the new Project.enabled_engarves list. (namengraves)
polyversion -t
command-line tool prints the full tag (not the version) to make it easy to know if it is a v-tag or r-tag.
3.13.3. Documentation changes¶
- Adopt towncrier for compiling CHANGES. So now each code change can describe its change in the same commit, without conflicts. (towncrier)
- usage: explain how to set your projects PEP 0518
pyproject.toml
file &setup_requires
keyword insetup.py
in your script. - add pbr, incremental and Zest.release in Similar Tools section as setuptools plugins.
- re-wrote and shrinked opening section using glossary terms.
- Chore development:
- deps: don’t pin packaging==17.1, any bigger +17 is fine for parsing version correctly.
3.14. 2018-05-24: 0.0.2a10: polyvers¶
- fix: slight change of default engraving for
setup.py:version=...
. - Remove default versions from the sources of our-own-dog-food (affects installations for developing this tool).
- refact: merged
`pvlib.whl
andpvlib.run
into a single executable and importable standalone wheel inbin/pvlib.run
, generated frompolyversion-0.0.2a9
, release below. - doc: expand section for installing and contributing into this project.
- chore: tighten various test harnesses.
3.14.1. 2018-05-24: 0.0.2a9: polyversion¶
2nd interim release to embed new bin/pvlib.run
.
- INVERT by default
polyversion()/polytime()
functions not to raise if vtags missing. - fix: pvlib.run shebang to use
#!/usr/bin/env python
to work on linux.
3.14.2. 2018-05-23: 0.0.2a8: polyversion¶
Interim release to embed new bin/pvlib.run
.
- FIX
polyversion
barebone command (a utility for when not installing the full polyvers tool). - feat: make project-name optional in
polyversion.polyversion()
; if not given, defaults to caller’s last segment of the module. - doc: rudimentary explanation of how to use the lib on its own README.
3.15. 2018-05-23: 0.0.2a9.post0: polyvers¶
- feat: add
-C
option to change project dir before running command. init
command:- fix: were creating invalid
.polyvers.yaml
configuration-file unless--monorepo/--mono-project
flags were given. - feat: include config-help in generated file only if
the new
--doc
flag given. - feat: inform user of the projects auto-discovered and what type of config-file was generated.
- fix: were creating invalid
- various fixes.
3.16. 2018-05-19: 0.0.2a8: polyvers¶
- FIX(bump): was engraving all projects and not limiting to those specified in the command-line - command’s syntax slightly changed.
- chore: Stop increasing polyversion version from now on.
- doc: fix all sphinx errors and API reference.
3.16.1. 2018-05-18: 0.0.2a7¶
Interim release to embed re-LICENSED pvlib/bin/pvlib.whl
,
from EUPLv1.2–>MIT
3.17. 2018-05-18: 0.0.2a6: bump
!¶
bump
command:- feat:
--amend
now works - feat:
--engrave-only
. - feat: log
PRETEND
while doing actions. - feat: Log which files where engraved in the final message.
- feat:
- fix(engrave): don’t waste cycles/log-messages on empty-matches (minor).
3.18. 2018-05-18: 0.0.2a5¶
Actually most changes happened in “interim” release v0.0.2a2, below.
- feat: make a standalone polyversion-lib wheel to facilitate bootstrap when installing & building from sources (and the lib is not yet installed).
- Add
bin/package.sh
that create the pvlib wheel as executabledist/pvlib.run
. - doc: fix rtd & pypi sites.
3.18.1. 2018-05-18: 0.0.2a4¶
doc: bad PyPi landing page.
3.18.2. 2018-05-17: 0.0.2a3¶
The pvcmd was actually broken so far; was missing polyversion lib dependency!
3.18.3. 2018-05-17: 0.0.2a2¶
Interim release to produce executable wheel needed by next release.
3.19. 2018-05-17: 0.0.2a1: monorepo!¶
- 2nd release, own “mono-project” splitted into 2-project “monorepo”: - polyvers: cmdline tool - polyversion: library code for program-sources to derive version from git-tags
- init, status, bump and config commands work.
- Read/write YAML config file
.polyvers.yaml
at the git-root, and can automatically discover used configuration (from existing git tags or projects files). - Support both
--monorepo
and--mono-project
configurations. - By default
__init__.py
,setup.py
andREADME.rst
files are engraved with bumped version.
3.19.1. 2018-05-16: 0.0.2a0¶
broken
3.20. 2018-01-29: 0.0.1a0: mono-project¶
- First release on PyPI as mono-project