=============================
FIX: engravings were applied unsorted (based on their start-point) and offsets
were miss-located when switching graft in a same file.
2018-07-05: polyversion-v0.2.1a0
================================
- Feature: The :envvar:`POLYVERSION_LOG_LEVEL` control *polyversion* verbosity.
Run ``polyversion -h`` fo help.
- Change: minor reordering when searching version from package-metadata.
- fix: add standalone ``bin/pvlib.run`` from last release.
- fix: :func:`~polyversion.polyversion()`/:func:`~polyversion.polytime()`
are guessing ``basepath`` keyword from the path of caller's top-package
(not just from caller's fpath).
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.
Features
--------
- Teach non-engraved projects how to retrieve polyversion when pip-installed:
- The functions :func:`~polyversion.polyversion()` & :func:`~polyversion.polytime()`
now attempt to fetch version from package/site-package infos.
- And the function doing this :func:`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.
Breaking Changes
----------------
- Rename :term:`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 from
``repo_path --> basepath`` to denote its importance for retrieving the version
of installed projects from sibling dirs inside ``PYTHONPATH/site-packages/``.
2018-06-29: polyversion-v0.1.1a3
================================
(change actually done in `v0.1.1a1`, just a fixes & doc-msg in `a2`)
- FIX: teach :term:`setuptools plugin` about :term:`default version env-var`.
Now can ``pip install git+https://some.git.repo/but-from/non-engraved-branch``.
2018-06-27: polyversion-v0.1.1a0
================================
- FEAT: Introduce configurable :term:`default version env-var` to fall-back
to :envvar:`<pname>_VERSION` if it exists, in case of errors (e.g. no git).
The presence of such a variable also sets ``polytime(no_raise=True)``,
which now also support the ``pname`` and ``default_version_env_var`` kwds.
2018-06-06: polyvers-v0.1.0a1, polyversion-v0.1.0a7
===================================================
Mostly docs, combined release.
+ FEAT: reinstated :term:`engravings` on ``_version.py``
(see previous release for rational).
2018-06-05: polyvers-v0.1.0a0, polyversion-v0.1.0a6: co2mpas-ready
==================================================================
+ FEAT: reinstated :term:`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 :term:`setuptools plugin` keyword, it is the `default_version` that
will be engraved, which is fine.
+ fix: report any version matched both from :term:`v-tag`\s and :term:`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.
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)
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.
(:git:`6519a1ba`)
- fix: `polyversion` stop eating half of its own dog food: cannot reliably use
:term:`setuptools plugin` for its installation. (:git:`56a894cde`)
- Monkeypatching *distutils* for :term:`bdist-check` was failing in *PY2*
due to being an "old class". (:git:`1f72baec`)
- doc: fixed recommendation about how to bypass :term:`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
...
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.
- `v0.1.0a0` had been canceled for the same reason, but somewhere down the road,
the fix was reverted (:term:`bdist-check` works for r-tag only).
- `v0.1.0a1` just marked that our ``setup.py`` files ate our dog food.
Breaking changes
-----------------
- Dropped all positional-arguments from :func:`polyversion.polyversion()`;
was error-prone. They have all been converted to keyword-arguments.
- Renamed data in :mod:`polyversion`
(also applied for :class:`polyvers.pvproject.Project()`)::
pvtag_frmt --> pvtag_format
vtag_frmt --> vtag_format
- Changed arguments in :func:`polyversion.polyversion()`
(affect also :class:`polyvers.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`` for :func:`polyversion.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 default :class:`~Project`'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
and ``polyvers bump`` would ignore it, and report +1 from the *v-tag*!
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 (see :func:`polyversion.init_plugin_kw`):
1. keyword: ``polyversion --> (bool | dict)``
When a dict, its keys roughly mimic those in :func:`polyversion()`,
and can be used like this:
.. code-block:: python
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'],
...
)
2. keyword: ``skip_polyversion_check --> bool``
When true, disable :term:`bdist-check`, when false (default),
any `bdist_*` (e.g. ``bdist_wheel``), commands will abort if not run
from a :term:`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).
- 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.
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 in ``setup.py`` in your script.
- add `pbr`, `incremental` and `Zest.release` in :ref:`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.