On Sep 7, 2015 12:51 PM, "Marcus Smith" <qwcode@gmail.com> wrote:
Wes, this isn't about the versioning scheme for Specs or PEPS. For *whatever* scheme we have, my discussion was about how to render all
the "current" versions we support in a Sphinx project. More or less itertools.product and a sphinx directive for ~CSVW? Marcus, we could change the subject line. The objective here, IIUC, is to generate and maintain the expanded set of packages and their metadata [[[ with the ability to download all/subset of the package metadata [ without having to execute each and every setup.py [ again ] ] ]]]. Possible subject lines: * [ ] Add RDFa to pypi and warehouse * [ ] Add JSONLD to pypi and warehouse * "PEP ???: Metadata 3.0.1" * "Re: [Python-ideas] Increasing public package discoverability (was: Adding jsonschema to the standard library)" * https://groups.google.com/d/msg/python-ideas/3MRVM6C6bQU/76hWP7bFgiwJ * https://groups.google.com/d/msg/python-ideas/3MRVM6C6bQU/VXq3yHcrCxcJ ``` So there is a schema.org/SoftwareApplication (or doap:Project, or seon:) Resource, which has * a unique URI (e.g. http://python.org/pypi/readme) * JSON metadata extracted from setup.py into pydist.json (setuptools, wheel) - [ ] create JSON-LD @context - [ ] create mappings to standard schema * [ ] http://schema.org/SoftwareApplication * [ ] http://schema.org/SoftwareSourceCode In terms of schema.org, a Django Packages resource has: * [ ] a unique URI * [ ] typed features (predicates with ranges) * [ ] http://schema.org/review * [ ] http://schema.org/VoteAction * [ ] http://schema.org/LikeAction ``` There is a matrix of packages that could, should, are uploaded; which is a subset of a [giant global] graph; which can be most easily represented in an RDF graph representation format like RDFa, JSON-LD, CSVW. * setup.py * requirements[-test|-docs][-dev][.peep].txt * tox.ini -- tox grid (+docker = dox) * Jenkins grid * --> Pypi (e.g. with twine) This does something more sequential than itertools.product w/ a Requirement namedtuple and a RequirementsMap to iterate through (for generating combinations of requirements-{test,dev,{extras}}: * https://github.com/westurner/pyleset/blob/57140bcef53/setup.py * https://github.com/westurner/pyleset/tree/57140bcef53/requirements
in short, should the current versions we want to publish be distinct documents or not.
The PEP workflow is probably fine
well, if you look up in the thread, a few of us are saying it's not. It doesn't distinguish Current Specs vs Proposals very well.
How would you add that metadata to the version string (according to PEP 440)? Semver 3.0 (pbr)
From http://docs.openstack.org/developer/pbr/semver.html : Example: 1.0.0.dev8 < 1.0.0.dev9 < 1.0.0.a1.dev3 < 1.0.0.a1 < 1.0.0.b2 < 1.0.0.c1 < 1.0.0
On Mon, Sep 7, 2015 at 9:40 AM, Wes Turner <wes.turner@gmail.com> wrote:
MAJOR.MINOR.PATCH[-rev] would be helpful for these (and other) PEPs.
On Sep 7, 2015 10:36 AM, "Marcus Smith" <qwcode@gmail.com> wrote:
I'm still unclear on whether you'd want A or B:
A) Different major/minor versions of the spec are different documents
From http://semver.org Semantic Versioning 2.0 :
``` Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes, - MINOR version when you add functionality in a backwards-compatible
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. ```
B) Different versions of the spec are tags or branches of the same document
From http://docs.openstack.org/developer/pbr/semver.html :
``` Linux/Python Compatible Semantic Versioning 3.0.0
This is a fork of Semantic Versioning 2.0. The specific changes have to do with the format of pre-release and build labels, specifically to make
Changes vs SemVer 2.0¶
dev versions are defined. These are extremely useful when dealing with
CI and CD systems when ‘every commit is a release’ is not feasible.All versions have been made PEP-440 compatible, because of our deep roots in Python. Pre-release versions are now separated by . not -, and use a/b/c rather than alpha/beta etc.
```
Something like v1.0.01-eb4df7f[-linux64] would have greater traceability.
If it's B, then you'd either: 1) only build the latest version, and construct an index of links to
manner, and them not confusing when co-existing with Linux distribution packaging and Python packaging. Inspiration for the format of the pre-release and build labels came from Python’s PEP440. the unrendered old versions in vcs history
2) use a custom build/publishing worflow that pulls versions out of history so they can be built as peers in the published version
#. TBH I'm more concerned about determining downstream tool support from MAJOR.MINOR.PATCH (The PEP workflow is probably fine; I think there is need for better versioning under one heading).
On Sun, Sep 6, 2015 at 9:26 PM, Nick Coghlan <ncoghlan@gmail.com>
wrote:
On 7 September 2015 at 14:11, Marcus Smith <qwcode@gmail.com> wrote:
> That way, the URL works as people expect, *and* the resulting > destination gives a URL that (when inevitably copy-and-pasted)
will
> retain its meaning over time.
Yes, ReadTheDocs does let us do that.
well, it lets you do it for a whole project.
RTD also has page redirects now:
https://read-the-docs.readthedocs.org/en/latest/user-defined-redirects.html#...
(I thought the same thing you did, but found that when double checking)
So we *could* redirect unqualified links to qualified ones if we wanted to. I just don't want to :)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig