Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 19.0 -- New year, New release #6106

Closed
pradyunsg opened this issue Jan 1, 2019 · 73 comments
Closed

Release 19.0 -- New year, New release #6106

pradyunsg opened this issue Jan 1, 2019 · 73 comments
Assignees
Labels
auto-locked Outdated issues that have been locked by automation type: maintenance Related to Development and Maintenance Processes
Milestone

Comments

@pradyunsg
Copy link
Member

Yet another issue for discussing yet another release. :)

@pradyunsg pradyunsg added this to the 19.0 milestone Jan 1, 2019
@pradyunsg pradyunsg added the type: maintenance Related to Development and Maintenance Processes label Jan 1, 2019
@pradyunsg
Copy link
Member Author

This one is a release with some heavy weight issues given that PEP 517 and manylinux2010 support are a part of it. There's also a bunch of "nicer error message" and VCS improvements here.

There's enough to justify a release here, clearly. I'm willing to be the RM for this release.

A quick question to @pfmoore, do you reckon PEP 517 should spend some time in a "beta" phase before being released?

@pfmoore
Copy link
Member

pfmoore commented Jan 3, 2019

If you mean do we need a prerelease, I don't think so. It's not something we've done that often in the past, and the PEP 517 changes should default back to legacy processing, so I'd be OK just going for a normal release. In my experience, very few people actually test the betas anyway.

I'm not against a beta (I think it would be better if we did have a standard process of doing prereleases) but I don't think the PEP 517 changes warrant one on their own.

@pradyunsg
Copy link
Member Author

That's what I meant.

We do have a standard process in terms of pre-releases in release cycles - if there's a pre-release, the main release is pushed ahead a month. It's documented in our release cadence docs.

@pfmoore
Copy link
Member

pfmoore commented Jan 7, 2019

We do have a standard process in terms of pre-releases in release cycles

What I meant was that I think we should routinely do prereleases, but thinking more about it, with releases every 3 months, prereleases are too much additional burden (and it's not like we'd get that much additional testing if we did do prereleases...) So just ignore that aside of mine.

@xavfernandez
Copy link
Member

While I think about it, it would be nice if a new packaging version could be released and vendored with pypa/packaging@eb02438

@pradyunsg
Copy link
Member Author

I can do a release of packaging - assuming @dstufft doesn't mind that, and merging a PR or giving me push access. :)

@xavfernandez
Copy link
Member

And we might want to add a deprecation warning for Python 3.4 support ?
19.0 might be the last version supporting 3.4 ?

@pradyunsg
Copy link
Member Author

I don't think we need a deprecation warning for that. We usually drop versions when the usage is low on PyPI.

I haven't run the bigquery SQL query to check what the numbers are, to facilitate us deciding that.

@xavfernandez
Copy link
Member

xavfernandez commented Jan 8, 2019

According to PyPI Stats, Python 3.4 represents ~3% of downloads.

If we plan to drop support for 3.4 in 19.1, we'll want a deprecation warning in 19.0 (à la 90b3db4#diff-84e592bd8e56a3c31ef7f6908753e4feL201).

@pfmoore
Copy link
Member

pfmoore commented Jan 8, 2019

+1 for dropping 3.4 in 19.1 and warning now.

@pradyunsg
Copy link
Member Author

Cool; let's do that.

@xavfernandez
Copy link
Member

In #6123, @pradyunsg makes a good point on our usual 6 months deprecation period (#6123 (comment)) so we might want to drop support in 19.2 ? cc @pfmoore

@pfmoore
Copy link
Member

pfmoore commented Jan 12, 2019

+1 that's a very good point

@pradyunsg
Copy link
Member Author

Super quick update -- there's 2 release blockers right now:

  • Preventing the NO_* environment variables confusion in PEP 517.
  • Updating vendored packages
    • I'll ping @dstufft regarding packaging again.

I intend to make a release on 22nd/23rd Jan - of course conditional to not having any blockers by then. If there are any concerns regarding what all is in the release, please flag them before/during the weekend.

@cjerdonek
Copy link
Member

@pradyunsg I noticed that a number of NEWS entries use single backticks to mark monospace when they should be double. So the NEWS entries should be reviewed before release.

@pradyunsg
Copy link
Member Author

Thanks @cjerdonek! I'll take care of that when cutting the release. :)

@pradyunsg
Copy link
Member Author

I can do a release of packaging [snip] giving me push access

Got this. Will do today or tomorrow.

@pradyunsg
Copy link
Member Author

#6147 is a new thing -- making it a part of this release.

Other than that and the packaging release/vendoring, if there are any changes, please ping here before merging PRs into master.

@cjerdonek
Copy link
Member

@pradyunsg, may I merge PR #6142? I thoroughly reviewed it a number of times, and it is well-tested.

/cc @fischman

@pradyunsg
Copy link
Member Author

Yeah sure, let's get that in as well. :)

@pradyunsg
Copy link
Member Author

pradyunsg commented Jan 20, 2019

https://pypi.org/project/packaging/19.0/ is up.

So, that means just 2 more PRs are left: #6151 and #6150.

@pradyunsg
Copy link
Member Author

Alrighty then.

That should be all for now; I'll let things stay settled for a couple of days just in case there's something else that might come up -- plus I have "mid" semester examinations -- so I intend to stick to the 22/23 Jan release date.

@cjerdonek
Copy link
Member

@pradyunsg I added PR #6153 to the release milestone.

It's a follow-up to the broken stdout pipe PR #5907. I noticed a tiny issue that occurs when a broken pipe happens when --log is also passed. I also included a test in the PR to prevent regressions.

@pradyunsg
Copy link
Member Author

pradyunsg commented Feb 9, 2019

Made the release. Pushed change to get-pip.py.

@pradyunsg
Copy link
Member Author

Reopened master for active development of 19.1. Thanks @pypa/pip-committers for letting me lock down master multiple times in this release cycle to avoid cherry-picking commits. :)

I don't think there's any need for a 19.0.3, unless someone files a show stopper bug in the next 3-4 days. Keeping this issue open for that case only.

Everything else can go into pip 19.1 development.

@gaborbernat
Copy link

https://pypi.org/project/virtualenv/16.4.0/ adopted it.

@pradyunsg
Copy link
Member Author

Any major-ish bugs reported for 19.0.2?

@cjerdonek
Copy link
Member

There's at least one regression from 19.0.1 to 19.0.2 (#6252), but I'm not sure how widely it will affect people. (Note: I think I might want to make one tiny tweak to my fix that was committed, which I can discuss separately.) There's also #6255 which is PEP 517-related, but it looks like it can be fixed strictly in setuptools?

@pradyunsg
Copy link
Member Author

I'm not sure how widely it will affect people.

I think that's pretty small impact bug and it's a case of better error messaging -- something I think we should aim to do for more cases related to PEP 517 in 19.1. This doesn't warrant a 19.0.3 IMO.

There's also #6255 which is PEP 517-related, but it looks like it can be fixed strictly in setuptools?

Yea, that's a setuptools bug.

@cjerdonek
Copy link
Member

I think that's pretty small impact bug and it's a case of better error messaging

No, it's not if you read the opening comment. Their build works in 19.0.1 but not in 19.0.2. It's not just better messaging because in 19.0.1 the error is caught, but in 19.0.2 it bubbles up and crashes pip.

@pradyunsg
Copy link
Member Author

Hmm... Fair enough. I think I read that wrong. I thought pip printed an IndexError and continued. Alrighty then, that'll be a 19.0.3.

I don't think there any other new issues so I'll probably make that release too; later tonight.

@pradyunsg
Copy link
Member Author

I don't think there any other new issues so I'll probably make that release too; later tonight.

Ah well, that didn't happen because a RL issue came up. I'll do it in the next 24 hours.

@dbelyavsky
Copy link

@pradyunsg so what do we think about 19.0.3?
kinda need it.

@cjerdonek
Copy link
Member

Someone needs to diagnose #6262 at some point.

@pradyunsg
Copy link
Member Author

I thought have commented here already - There's more time needed to figure out existing bugs filed for regressions from 19.0.2. Putting off the 19.0.3 release until we figure that out.

Sorry for the false alarm on the release plan.

@pradyunsg
Copy link
Member Author

Someone needs to diagnose #6262 at some point.

That doesn't seem like a pip issue to me tbh.

@cjerdonek
Copy link
Member

There's more time needed to figure out existing bugs filed for regressions from 19.0.2.

@pradyunsg Are there any remaining potential 19.x bugs you know of? I haven't seen any myself, and I've been keeping an eye out.

@pradyunsg
Copy link
Member Author

@pradyunsg Are there any remaining potential 19.x bugs you know of?

Nope. I've mostly been busy with some prototyping lately.

I think we're golden for 19.0.3 now.

@pradyunsg
Copy link
Member Author

Cool, cutting a 19.0.3 in the next 24 hours, from the current master because I'm lucky and no one merged any non 19.0.3 bug fixes. ;)

@pradyunsg
Copy link
Member Author

pradyunsg commented Feb 20, 2019

I've started with the release engineering for 19.0.3, from current master.

@pradyunsg
Copy link
Member Author

Made the release. Updated get-pip.py.

I don't think there's any need for a 19.0.3, unless someone files a show stopper bug in the next 3-4 days. Keeping this issue open for that case only.

s/19.0.3/19.0.4/

@pradyunsg
Copy link
Member Author

Alrighty. That closes this release cycle. I'll file the CPython PR in a bit.

Thanks to everyone who helped out in the form of PRs, discussion or any other contributions in this release cycle! :D

atipi referenced this issue in vilkasgroup/Pakettikauppa Feb 28, 2019



### Update [pip](https://pypi.org/project/pip) from **18.1** to **19.0.1**.


<details>
  <summary>Changelog</summary>
  
  
   ### 19.0
   ```
   =================

Deprecations and Removals
-------------------------

- Deprecate support for Python 3.4 (`6106 &lt;https://github.com/pypa/pip/issues/6106&gt;`_)
- Start printing a warning for Python 2.7 to warn of impending Python 2.7 End-of-life and
  prompt users to start migrating to Python 3. (`6148 &lt;https://github.com/pypa/pip/issues/6148&gt;`_)
- Remove the deprecated ``--process-dependency-links`` option. (`6060 &lt;https://github.com/pypa/pip/issues/6060&gt;`_)
- Remove the deprecated SVN editable detection based on dependency links
  during freeze. (`5866 &lt;https://github.com/pypa/pip/issues/5866&gt;`_)

Features
--------

- Implement PEP 517 (allow projects to specify a build backend via pyproject.toml). (`5743 &lt;https://github.com/pypa/pip/issues/5743&gt;`_)
- Implement manylinux2010 platform tag support.  manylinux2010 is the successor
  to manylinux1.  It allows carefully compiled binary wheels to be installed
  on compatible Linux platforms. (`5008 &lt;https://github.com/pypa/pip/issues/5008&gt;`_)
- Improve build isolation: handle ``.pth`` files, so namespace packages are correctly supported under Python 3.2 and earlier. (`5656 &lt;https://github.com/pypa/pip/issues/5656&gt;`_)
- Include the package name in a freeze warning if the package is not installed. (`5943 &lt;https://github.com/pypa/pip/issues/5943&gt;`_)
- Warn when dropping an ``--[extra-]index-url`` value that points to an existing local directory. (`5827 &lt;https://github.com/pypa/pip/issues/5827&gt;`_)
- Prefix pip&#39;s ``--log`` file lines with their timestamp. (`6141 &lt;https://github.com/pypa/pip/issues/6141&gt;`_)

Bug Fixes
---------

- Avoid creating excessively long temporary paths when uninstalling packages. (`3055 &lt;https://github.com/pypa/pip/issues/3055&gt;`_)
- Redact the password from the URL in various log messages. (`4746 &lt;https://github.com/pypa/pip/issues/4746&gt;`_, `6124 &lt;https://github.com/pypa/pip/issues/6124&gt;`_)
- Avoid creating excessively long temporary paths when uninstalling packages. (`3055 &lt;https://github.com/pypa/pip/issues/3055&gt;`_)
- Avoid printing a stack trace when given an invalid requirement. (`5147 &lt;https://github.com/pypa/pip/issues/5147&gt;`_)
- Present 401 warning if username/password do not work for URL (`4833 &lt;https://github.com/pypa/pip/issues/4833&gt;`_)
- Handle ``requests.exceptions.RetryError`` raised in ``PackageFinder`` that was causing pip to fail silently when some indexes were unreachable. (`5270 &lt;https://github.com/pypa/pip/issues/5270&gt;`_, `5483 &lt;https://github.com/pypa/pip/issues/5483&gt;`_)
- Handle a broken stdout pipe more gracefully (e.g. when running ``pip list | head``). (`4170 &lt;https://github.com/pypa/pip/issues/4170&gt;`_)
- Fix crash from setting ``PIP_NO_CACHE_DIR=yes``. (`5385 &lt;https://github.com/pypa/pip/issues/5385&gt;`_)
- Fix crash from unparseable requirements when checking installed packages. (`5839 &lt;https://github.com/pypa/pip/issues/5839&gt;`_)
- Fix content type detection if a directory named like an archive is used as a package source. (`5838 &lt;https://github.com/pypa/pip/issues/5838&gt;`_)
- Fix listing of outdated packages that are not dependencies of installed packages in ``pip list --outdated --not-required`` (`5737 &lt;https://github.com/pypa/pip/issues/5737&gt;`_)
- Fix sorting ``TypeError`` in ``move_wheel_files()`` when installing some packages. (`5868 &lt;https://github.com/pypa/pip/issues/5868&gt;`_)
- Fix support for invoking pip using ``python src/pip ...``. (`5841 &lt;https://github.com/pypa/pip/issues/5841&gt;`_)
- Greatly reduce memory usage when installing wheels containing large files. (`5848 &lt;https://github.com/pypa/pip/issues/5848&gt;`_)
- Editable non-VCS installs now freeze as editable. (`5031 &lt;https://github.com/pypa/pip/issues/5031&gt;`_)
- Editable Git installs without a remote now freeze as editable. (`4759 &lt;https://github.com/pypa/pip/issues/4759&gt;`_)
- Canonicalize sdist file names so they can be matched to a canonicalized package name passed to ``pip install``. (`5870 &lt;https://github.com/pypa/pip/issues/5870&gt;`_)
- Properly decode special characters in SVN URL credentials. (`5968 &lt;https://github.com/pypa/pip/issues/5968&gt;`_)
- Make ``PIP_NO_CACHE_DIR`` disable the cache also for truthy values like ``&quot;true&quot;``, ``&quot;yes&quot;``, ``&quot;1&quot;``, etc. (`5735 &lt;https://github.com/pypa/pip/issues/5735&gt;`_)

Vendored Libraries
------------------

- Include license text of vendored 3rd party libraries. (`5213 &lt;https://github.com/pypa/pip/issues/5213&gt;`_)
- Update certifi to 2018.11.29
- Update colorama to 0.4.1
- Update distlib to 0.2.8
- Update idna to 2.8
- Update packaging to 19.0
- Update pep517 to 0.5.0
- Update pkg_resources to 40.6.3 (via setuptools)
- Update pyparsing to 2.3.1
- Update pytoml to 0.1.20
- Update requests to 2.21.0
- Update six to 1.12.0
- Update urllib3 to 1.24.1

Improved Documentation
----------------------

- Include the Vendoring Policy in the documentation. (`5958 &lt;https://github.com/pypa/pip/issues/5958&gt;`_)
- Add instructions for running pip from source to Development documentation. (`5949 &lt;https://github.com/pypa/pip/issues/5949&gt;`_)
- Remove references to removed ``egg=&lt;name&gt;-&lt;version&gt;`` functionality (`5888 &lt;https://github.com/pypa/pip/issues/5888&gt;`_)
- Fix omission of command name in HTML usage documentation (`5984 &lt;https://github.com/pypa/pip/issues/5984&gt;`_)
   ```
   
  
</details>


 

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/pip
  - Changelog: https://pyup.io/changelogs/pip/
  - Homepage: https://pip.pypa.io/
</details>





### Update [tox](https://pypi.org/project/tox) from **3.6.1** to **3.7.0**.


*The bot wasn't able to find a changelog for this release. [Got an idea?](https://github.com/pyupio/changelogs/issues/new)*

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/tox
  - Docs: https://tox.readthedocs.org/
</details>





### Update [PyYAML](https://pypi.org/project/PyYAML) from **4.2b1** to **4.2b4**.


*The bot wasn't able to find a changelog for this release. [Got an idea?](https://github.com/pyupio/changelogs/issues/new)*

<details>
  <summary>Links</summary>
  
  - PyPI: https://pypi.org/project/pyyaml
  - Homepage: http://pyyaml.org/wiki/PyYAML
</details>
@lock
Copy link

lock bot commented May 28, 2019

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.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label May 28, 2019
@lock lock bot locked as resolved and limited conversation to collaborators May 28, 2019
@pradyunsg pradyunsg changed the title New year, New release (Release 19.0) Release 19.0 -- New year, New release Nov 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation type: maintenance Related to Development and Maintenance Processes
Projects
None yet
Development

No branches or pull requests

7 participants