2018-06-06: polyvers-v0.1.0a1, polyversion-v0.1.0a7

Mostly docs, combined release.

CHANGES:

2018-06-06: polyvers-v0.1.0a1, polyversion-v0.1.0a7

• FEAT: reinstated :term:engravings on _version.py
  (see previous release for rational).

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.0a2Canceled (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.