The RFC links are generated by Sphinx, looks like they're using an outdated
base URL. I opened a ticket to report the issue and cut a quick PR to fix:
* https://github.com/sphinx-doc/sphinx/issues/9857
* https://github.com/sphinx-doc/sphinx/pull/9858
--
Distutils-SIG mailing list -- distutils-sig
Feel free to send a pull request to fix this. You can find the link to the PEP
repository at the bottom of the page.
--
Tzu-ping Chung (@uranusjr)
uranu...@gmail.com
https://uranusjr.com
On Nov 4 2021, at 2:24 am, Johnathan Irvin wrote:
> Noticed the link was broken for RFC 2119.
>
> I believe i
On 2021-04-27 20:32:07 +1000 (+1000), Nick Coghlan wrote:
[...]
> The simplest resolution would be to drop the ".taskslab11419" section, and
> just make the version 0.2.0 instead. Alternatively, if keeping the number
> is important, you could make a dev release (0.2.0.dev11419), or use a 4
> segmen
Hi Bianca,
The ".taskslab11419" section of your version name doesn't meet the
requirements for version numbers described in
https://www.python.org/dev/peps/pep-0440/#public-version-identifiers, as
the only non-numeric text elements permitted are "a" (alpha releases), "b"
(beta releases), "c" (rele
On Fri, Mar 1, 2019, at 9:59 AM, Sofia Nunes wrote:
> So, let’s assume I fork a package which is on version 2.1. and change its
> name.
> Would my distribution version be 1.0 or 2.2/3.0? Or none of the options?
From a technical perspective, I don't think it matters: if your fork has a new
name,
On Fri, 18 Jan 2019 at 03:17, Michael Goerz wrote:
>
> PEP 440 contains a section that claims:
>
> > Summary of differences from pkg_resources.parse_version
> > [https://www.python.org/dev/peps/pep-0440/#id63]
> >
> > * Local versions sort differently, this PEP requires that they sort as
> > gr
