Skip to content

Releases: ankostis/polyvers

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

08 Jun 11:50
polyvers-v0.1.0a1
Compare
Choose a tag to compare

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.