So I am super enthused about the acceptance of PEP440 since it provides
some useful structure to the version attribute. I am trying to reconcile
its usage with my release cycle and ran into a snag. The release cycle
that I use is pretty simple.
1. A final release version (e.g., 1.1, 1.0.3) is represented by a tag in
the SCM (currently git)
2. Development releases are incremental additions to the last release
version but are not necessarily API compatible. They are released
internally when changes are merged into "master".
3. The next "final release" version is not known until it is released.
IOW, the decision on which portion of the release segment to bump
is delayed until it is tagged.
Before PEP-440, we used a scheme like:
N(.N)*[-X-R]
Where ``N(.N)*`` is the most recent release version derived directly from
the SCM tag. The ``-X-R`` suffix designates a post release that is not
necessarily compatible with the previous final release version. The
``X`` is the number of commits into master since the last tag and the
``R`` segment is the SCM revision (e.g., git committish).
I cannot figure out how to support not knowing what the next version is
going to be while remaining PEP-440 compliant. My initial thought was to
use ``.postX`` to track the number of commits ahead of the most recent
tag and stick the SCM revision information in metadata. The catch is that
post releases are required to be compatible with the final release
identified by the prefix.
Has anyone else run into similar difficulties? I'm guessing that I am
over-thinking things again and no one really worries about such details.
Any advice (even opinions) very much appreciated.
- dave
--
"State and behavior. State and behavior. If it doesn't bundle state
and behavior in a sensible way, it should not be an object, and there
should not be a class that produces it." eevee
--
https://mail.python.org/mailman/listinfo/python-list
