latest version mismatch

http://docs.python-requests.org/en/latest/ currently corresponds to "Release v2.3.0". But running "pip install requests" gives

```
$ pip install -v requests
Downloading/unpacking requests
  Using version 2.2.1 (newest of versions: 2.2.1, 2.2.1, 2.2.0, 2.2.0, 2.1.0, 2.1.0, 2.0.1, 2.0.1, 2.0.0, 2.0.0, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.0, 1.0.4, 1.0.3, 1.0.2, 1.0.1, 1.0.0, 0.14.2, 0.14.1, 0.14.0, 0.13.9, 0.13.8, 0.13.7, 0.13.6, 0.13.5, 0.13.4, 0.13.3, 0.13.2, 0.13.1, 0.13.0, 0.12.1, 0.12.0, 0.11.2, 0.11.1, 0.10.8, 0.10.7, 0.10.6, 0.10.4, 0.10.3, 0.10.2, 0.10.1, 0.10.0, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.9, 0.8.8, 0.8.7, 0.8.6, 0.8.5, 0.8.4, 0.8.3, 0.8.2, 0.8.1, 0.8.0, 0.7.6, 0.7.5, 0.7.4, 0.7.3, 0.7.2, 0.7.1, 0.7.0, 0.6.6, 0.6.5, 0.6.4, 0.6.3, 0.6.2, 0.6.1, 0.6.0, 0.5.1, 0.5.0, 0.4.1, 0.4.0, 0.3.4, 0.3.3, 0.3.2, 0.3.1, 0.3.0, 0.2.4, 0.2.3, 0.2.2, 0.2.1, 0.2.0)
  Downloading requests-2.2.1-py2.py3-none-any.whl (625kB):
...
```

Is 2.3.0 not in fact released yet, or has it just not yet been uploaded to PyPI?


Looks like there's no 2.3.0 tag at https://github.com/kennethreitz/requests/tags yet, so I take it 2.2.1 is in fact the latest version, and the http://docs.python-requests.org/en/latest/ page is showing an incorrect latest version.


Correct, 2.3.0 is a long way off. In a breach of the way we normally do things, a Pull Request incremented the version number well before release which invalidates the docs. Probably the best thing to do at this stage is to roll the version number back to 2.2.1.


@Lukasa I didn't trigger this but I prefer it this way. Certain things have been fixed/broken in 2.3.0. That behaviour is not available/visible in 2.2.1 and so the documented behaviour is accurately documented. :)


Thanks for the info @lukasa.

Do we all agree the current info on the
http://docs.python-requests.org/en/latest/ page is misleading, as it
(a) calls 2.3.0 "released", and (b) calls it "latest" (in the url)? From
that I'd conclude 2.3.0 was the latest release.

On Wednesday, March 19, 2014, Ian Cordasco
<notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

> @Lukasa https://github.com/Lukasa I didn't trigger this but I prefer it
> this way. Certain things have been fixed/broken in 2.3.0. That behaviour is
> not available/visible in 2.2.1 and so the documented behaviour is
> accurately documented. :)
> 
> ## 
> 
> Reply to this email directly or view it on GitHubhttps://github.com/kennethreitz/requests/issues/1968#issuecomment-38116629
> .


If you change the current latest version to something like "2.3.0-dev" (and
then update the docs, ideally substituting "release" with "version" for
docs on not-yet-released versions) it'd be clearer, and more semantic too.

On Wednesday, March 19, 2014, _pants@getlantern.org wrote:

> Thanks for the info @lukasa.
> 
> Do we all agree the current info on the
> http://docs.python-requests.org/en/latest/ page is misleading, as it
> (a) calls 2.3.0 "released", and (b) calls it "latest" (in the url)? From
> that I'd conclude 2.3.0 was the latest release.
> 
> On Wednesday, March 19, 2014, Ian Cordasco notifications@github.com
> wrote:
> 
> > @Lukasa https://github.com/Lukasa I didn't trigger this but I prefer
> > it this way. Certain things have been fixed/broken in 2.3.0. That behaviour
> > is not available/visible in 2.2.1 and so the documented behaviour is
> > accurately documented. :)
> > 
> > ## 
> > 
> > Reply to this email directly or view it on GitHubhttps://github.com/kennethreitz/requests/issues/1968#issuecomment-38116629
> > .


I'm honestly not sure what to do here. On my own projects I have a separate set of 'development' docs.


@skivvies this isn't standard procedure for requests. Reverting the version bump seems silly at this point and changing it to 2.3.0-dev will only invoke Kenneth's ire. For now I vote we leave this alone. After 2.3.0 this just won't happen. 


Does requests follow the http://semver.org spec?

> A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

It sounds like that could help avoid something like this in the future (e.g. right after publishing a final release, there's an immediate followup commit to bump the version on master to something like X.Y.Z-dev (where X.Y.Z is the next planned release).

If there's interest, I can open a ticket for that separately.


We follow semver, but we don't do pre-releases, and we shouldn't do it here.

Our actual releases, by which I mean our releases on pip and our git tags, follow semver. Anything else is development and may be wrong from time to time.


Sorry for the confusion, I wasn't suggesting _publishing_ pre-releases, but rather just doing the automatic version bump to a pre-release version on master immediately after publishing a release. That way, if docs accidentally get published for a pre-release version, it's obvious they're for a pre-release version. It also makes it obvious during development that it's a pre-release version when you can inspect the package version and see something like `-dev` at the end.


This is really up to @kennethreitz, but I suspect he's going to want to avoid the extra procedural overhead.


This has been discussed a few times in the past but has never been something Kenneth was in favor of. Whoever bumped the version number this time got lucky and it slipped past all of us. Usually that doesn't happen.