Release 18.0

[pradyunsg]

As per #4981 (comment), here's a dedicated issue for discussing the next major release.

As far as I can tell, we have enough changes and fixes to justify a new release in July as per our new release cadence.

[pradyunsg]

There's NEWS fragments about unvendoring and adding tests; they'll need to be removed or the final news file updated to remove them.

[pfmoore]

@pradyunsg Are you still interested in doing the release management for this? If not, then I'll be willing to cover it again.

[pradyunsg]

@pfmoore I am interested in doing the release management for this. :)

[pradyunsg]

I just noticed that we never actually got around to removing items marked for deprecation in pip 11: https://github.com/pypa/pip/search?q=RemovedInPip11Warning&unscoped_q=RemovedInPip11Warning

Also, I think we have to update the exceptions in pip._internals.utils.deprecation as per our new deprecation policy.

[pradyunsg]

I just noticed that we never actually got around to removing items marked for deprecation in pip 11: pypa/pip/search?q=RemovedInPip11Warning&unscoped_q=RemovedInPip11Warning

#5523

I think we have to update the exceptions in pip._internals.utils.deprecation as per our new deprecation policy.

A functional doubt: should we mention a GH issue number in our deprecation messages to make it more obvious where to provide feedback for a deprecation? I don't think we'd need it for all of the things we'd deprecate but I do think providing a link might make people more conducive to provide feedback.

[pradyunsg]

@pfmoore I remember you saying after 10.0 that you'd add some information to the documented release process. By any chance do you recall what it was about? Or am I mis-remembering (is that a word?)?

[pfmoore]

Bleh. Sorry, I don't. I may have done it, but I can't be sure. I'll try to go back and confirm what it was. But if I don't get to it in the next day or two, I'll be away for a couple of weeks, so please ping me again after that.

PS mis-remembered is a perfectly good word. More than I can say for "bleh" :-)

[pradyunsg]

Roger that. :)

[pradyunsg]

Does anyone in @pypa/pip-committers want to be the release manager for 18.0? If not, would you mind if I am the release manager for this release?

[pfmoore]

I'm fine with you doing it. Real life commitments mean I probably won't have the time, although I would like to do it again at some point.

BTW, regarding numbering, I think we should be going for 18.1 = the first release in 2018, 18.2 = the second release, etc. 18.0 still gives the impression to me of "major release = 18, minor release = 0". Not a huge deal, but I prefer counting from 1 for something that's a pure "the Xth release this year" marker.

[pradyunsg]

I'm fine with calling it 18.1 (or even 18.1.0 -- year.feature-release.bug-fix). We can bikeshed till eternity though. :P

[pradyunsg]

Pinging @dstufft and @xavfernandez.

[xavfernandez]

18.0 seems more natural to me (or maybe 18.7 if we include the month).
Or 11.0 is also fine ;)

[dstufft]

I don't have a strong preference, but I prefer 18.0, just because I'm used to zero indexed counting. X.Y.0 vs X.Y doesn't matter, when comparing those versions they're considered equal anyways. I would write it in the code as X.Y.0 though just to keep the 3 part version number.

[pfmoore]

Count me convinced. The bikeshed should have a "0" painted on it ;-)

[pradyunsg]

Wait, so, is it 18.0 or 18.0.0? IIUC, it's 18.0 (like the milestone currently)

[pfmoore]

Sorry - I'm convinced on 18.0 rather than 18.1. I'm going to duck on 18.0.0 and say that as release manager you can choose ;-) I think there was a discussion somewhere (in the dev docs rework PR, maybe?) but I'm not going to hunt it down - still unpacking from holidays...

[dstufft]

18.0 vs 18.0.0 does not really, matter, they're literally the same version as far as all of the tooling is concerned. It's only a display issue.

[pradyunsg]

I'll just go with 18.0; it's what's basically written everywhere anyway.

[pradyunsg]

Could someone add me to the PyPI and TestPyPI projects for pip? My username's pradyunsg there.

[pradyunsg]

Should we hold off pip 18.0 till the discussion about PEP 518's edge case is finalized?

I'm personally fine with the behavior change that pip 18.0 brings in that regard (just printing a warning when the key is missing saying we might change the behavior, add the key) so I've not marked it as such. I'm not sure how the release might contribute to the confusion (that I already feel I've mostly caused) in the discussion there.

[pfmoore]

No, we've moved to time-based releases where we release what's on master. We shouldn't reverse that decision before we've even done the first release :-)

OTOH, I remain confused as to what precisely you think needs changing, in any of the 3 cases:

1. Decision not made yet - I assume we need no changes in that situation. Why would we?
2. build-system is mandatory - I don't think we need a change, although there may be a "nice to have" improved error message. But there's not even a PR for that yet, and it's certainly not a release blocker.
3. build-system is optional - We still don't need a change. Just because build-system is optional doesn't mean we can't still choose to trigger isolation based on the presence of pyproject.toml. And I haven't seen a strong argument to backtrack on the decision we made in pip 10 to do so.

I think PEP 518 is a red herring here. We have to deal with all 3 cases - projects with no pyproject.toml, projects with pyproject.toml that only contains tool config, and projects with a full PEP 518 pyproject.toml. What we do is clearly defined at the moment (isolate if pyproject.toml exists, legacy code path if it doesn't), and there's no need to change it. The only possible relevance of the PEP 518 discussion is around how we describe (either in conversations on the tracker, or in error/warning messages in pip) the situation.

I don't necessarily like the fact that if a project adds config for towncrier, pip changes the way it builds the project. But it wasn't me that decided that towncrier would use a file described as being for "specifying build system requirements" for its configuration, so I'm not going to cry about it. If we were getting loads of bug reports from people hitting a lot of difficult-to-resolve consequences of the change, I might think differently. But we're not, so I don't.

[dstufft]

I haven't been following the PEP 518 discussion, but there are basically only a few choices ATM (in general):

1. If something has changed in the master branch, is the change correct or does the change need more time? If It is not correct or it needs more time, revert it.
2. If something has not changed in the master branch, but there is discussion about changing it, then the release does not wait, there will be another one in a few months it can hopefully make it into.

Those are basically the only questions a release manager needs to ask. The idea behind the time based releases is we do not wait for a change, either the master branch is ready to go, or we keep the status quo established in the previous release.

[dstufft]

That being said, we intentionally left the exact release day vague (some time in July), so that if there is something where we need 1-2 days to figure out the answers, that is OK.

[pradyunsg]

Right. I'm happy with the master as it stands on this issue.

@pfmoore all of what you said is exactly what I had in mind too - I just wanted to cross check if anyone thinks differently on this or not. :)

[pradyunsg]

Alrighty then, there's only 2 release blockers in the milestone right now and it seems to me that those are both good to go [1]. If there's any other release blockers, please tag them as such, add them to the milestone and link to them from here.

The current plan, assuming no new blockers, I'll be making a TestPyPI release during the weekend (21st-22nd) and the final PyPI release on the following Monday (23rd). If we need any bug-fix releases, I'll have the time for making them during both the weekends after the main release (29th, 4th).

@pfmoore @dstufft Could one of you add me to pip on PyPI and TestPyPI so I can actually upload the releases, when the time comes? :)

---

[1]: I'd like inputs from other @pypa/pip-committers on them; I am happy to merge them as is too if no one has the time to look at them.

[pfmoore]

What's your username on PyPI?

[pradyunsg]

pradyunsg

[pfmoore]

Thanks (I know it's easy to guess, but I didn't see a search box on PyPI and I wanted to avoid mistakes).

Done on both PyPI and test PyPI.

[pfmoore]

BTW, at some point we should probably document all the little bits that need doing when we add a new core committer, so we can get them all done at once in the future :-)

[pradyunsg]

BTW, at some point we should probably document all the little bits that need doing when we add a new core committer, so we can get them all done at once in the future :-)

That sounds like something that can be filed as a separate issue. :)

[pradyunsg]

That sounds like something that can be filed as a separate issue. :)

#5612

[pfmoore]

Thanks :-)

[pradyunsg]

I'll make the TestPyPI release tomorrow morning (so, ~15 hours from now). If someone has any concerns that would be release blockers, now would be the last chance to let me know. :)

[pamolloy]

I guess it's too late now, but please use 2018 instead of 18. People will see 18 and be confused how they missed 7 releases until they find this conversation. The extra two characters add clarity at the expense of just two characters. In the future people will see releases like 18.2.5 and assume semantic versioning or something similar.

Have you looked at other projects? See https://github.com/buildroot/buildroot/releases

[pfmoore]

@pamolloy Yeah, it's too late. This was discussed and agreed a while back in #5324 so we're not going to change it now.

[pradyunsg]

Alrighty then, I'll start with prepping for release.

@pypa/pip-committers Please don't merge any PRs between now and until there's pip 18.0 on PyPI. :)

[pradyunsg]

There's a small change in plan: since the NEWS file contains the date, I'll make the PyPI release today itself (instead of Monday/tomorrow) to ensure the dates on TestPyPI, PyPI and NEWS be the same.

PS: The release process (and associated docs) definitely can be improved. I'm taking notes on what I'm doing right now, to concretely suggest what I feel should be changed there (will do after the release is done).

[pradyunsg]

TestPyPI release is made. Releasing on PyPI in a bit...

[pradyunsg]

Released pip==18.0 on TestPyPI and PyPI using setuptools==40.0.0, wheel==0.31.1 and twine==1.11.0.

[pfmoore]

I assume you'll announce on the mailing lists when the final release is done? It would probably be worth including details of the change to calver and our new release cadence in the release note.

[pradyunsg]

I assume you'll announce on the mailing lists when the final release is done? It would probably be worth including details of the change to calver and our new release cadence in the release note.

Yeah. I am planning to announce on pypa-dev and distutils-sig. Will do after lunch. :)

[pradyunsg]

master is open for development again. Feel free to merge PRs as you normally would.

If we need a bugfix release, I'll cherry-pick the changes for it. Let's keep this issue open for a few days, in case we need a bug-fix release.

[pradyunsg]

Updated get-pip.py and updated get-pip.py for Python 3.3 as well.

Made an announcement on pypa-dev and distutils-sig: https://mail.python.org/mm3/archives/list/distutils-sig@python.org/thread/AQBMJKBON6WJ5S53WTHLZN7LXLP43L2Y/

[dstufft]

Awesome! Great work. Glad that both Paul and Pradyun have done releases now :)

[thehesiod]

looks like NEWS.rst isn't making it to https://pypi.org/project/pip/, I was surprised to find it blank when I tried to figure out why pip jumped from 10->18. Logged bug: #5655

[pradyunsg]

ISTM there have been no bugs introduced that would need a bug fix release.

I'm gonna go ahead and call it a wrap for 18.0, and close this issue.

Thanks again to everyone who contributed to this release! Onwards to 18.1. :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.