tractor
tractor copied to clipboard
goodboy
Versioning scheme and related release policies
As per some discussion in #104 we'll figure out the "best" (read most hip) versioning scheme after we get an initial dev release on the ol' pypi.
Some notes from discussion I've had with @salotz:
- there's a pep 440 for dev releases
- @salotz has a cool idea for a so called semantic changelog
- the philosophy of growth versioning
- consideration for codetags
Since then I've come up with some practical usages for the different tags. Ignoring alphas I make a series of rc releases to allow for usage and finding missed bugs. Then you can do dev releases in between to "debug" the actual packaging release process itself. I.e. if you screw up and forget to include necessary files in the dist.
For reference I keep a fairly up to date cookiecutter: https://github.com/salotz/salotz-py-cookiecutter/tree/master/%7B%7Bcookiecutter.project_slug%7D%7D
Dev guide: https://github.com/salotz/salotz-py-cookiecutter/blob/master/%7B%7Bcookiecutter.project_slug%7D%7D/info/dev_guide.org#releases
Not sure the goal for this issue, but basically what is written there is what I would do. You can review in that repo if you want.
Not sure the goal for this issue, but basically what is written there is what I would do. You can review in that repo if you want.
@salotz mostly discussion and archiving all the above links :smiley_cat:
I would like to automate the release process and change-log if possible with something like towncrier or whatever is hip now.
Ok cool. You know me well to assign vaguely purposeful conversation :P
re towncrier. I might suggest to just roll our own since basically their configuration is most of the same stuff you would configure in building a static site via e.g. Nikola. Which is quite easy to do.
That said rendering HTML is second priority to good practices of writing them, having a clean process, etc.
I usually have both a changelog for releases as well as a "news" feed. You can add semantics to the changelog potentially like towncrier leaving your news free of such shackles.
Oh I was also going to mention that using setuptools_scm is probably a cool idea.
We use it a bunch in the pytest community projects and I've found it quite nice for avoiding managing versions by hand.
Follow up discussion from #104.
- https://semver.org/#faq
- we could try versioneer for incremental automatic tagging from
git - @richardsheridan's PR showing the modern dev's installation system setup closely mirroring
trio's - can can consider using
setup.cfgto read in the version usingversion= :attr tractor.__version__- example from twisted: https://github.com/twisted/twisted/blob/trunk/setup.cfg#L3
@richardsheridan yeah see calver has always appealed to me ever since seeing in salt-stack way back: https://calver.org/
I personally prefer the time linking since it just gives the reader so much more info from the outset.