Next release after 20.8b1 (and include wheels this time!)

[ichard26]

Description & why

Publish a new release that has wheels. It's been a long time since the previous release and many features and bugfixes have been added since then. Also the current release (20.8b1) doesn't have wheels which is an issue for several reasons:

• Windows embedded installations unusable: Black install via pip fails on embedded Python on Windows using latest pip version (20.3) #1847
• Version mismatches during sdist build: Black version number is not properly set when downloading from source and installing from PyPi.  #1910
• Just other inconveniences because building our sdist requires setuptools and wheel: Failed to install offline #2031

Additional context

I'm opening this issue to serve as the location for communication of the status on the next release. There's a bunch of issues that show why a new release with wheels is important but nothing to point users at for further information.

Also I'd appreciate if technical details could be posted here to provide context to users.

One final point

As a maintainer of the project whose power is limited (only triage perms + RTD admin access), I'm frustrated this has been met with many delays.

I'd call on my fellow maintainers to work on the following points:

• Provide more clarity on the status release until one is released
• Conduct a post-mortem after release and make any necessary changes to how responsibilities and duties are distributed among the core team to reduce delays and blockers

[pradyunsg]

Let me know if you want help with automation around releases here. I'm happy to help and contribute toward documenting your processes as well.

I think getting something like https://pip.pypa.io/en/stable/development/release-process/#id5 or even https://pradyunsg.me/furo/contributing/workflow/#release-process isn't that difficult for most pure-Python packages.

I've been doing a bunch of this recently across quite a few projects, and reducing it down to a single CLI command like nox -s release on a maintainers machine is a great experience IMO.

[ichard26]

Matter of fact, we have automation to publish a new release to PyPI setup and ready to go: https://github.com/psf/black/blob/master/.github/workflows/pypi_upload.yml

It's not clear who's in charge of releases. I know @cooperlees is willing to step up in this area but we still haven't made any (IMO) clear decisions. Also there's just not many policies around here. As you have noted, there's no release schedule which is also an issue. Personally I'd like to see release tracking issues (like pip's) being used to help increase transparency and communication between the community and us the core team.

Now I need to make it clear that I don't want to point fingers here, we're all quite busy and us the core team is no different. I'm lucky to be able to work on Black for (relatively speaking) a lot of time, and I probably spend too much time in the issues tab on this repository for my own good. But I do want the project to be more maintainable and resilient to changes to the core team (we have a bunch of inactive maintainers which is perfectly OK, life happens, but these events should be planned for to reduce impact).

Also, thank you @pradyunsg!

---

I'm going to step away from F/OSS work for a little bit to cool off a bit. This situation is honestly quite frustrating and I'm sure some of it is showing here. I'm still grateful to be able to work on such an important project and for the things I've learned here.

[cooperlees]

Thanks all for raising this. I have been persistent asking those with access to cut releases, but we've all failed to do so. I've been trying to automate black's release process in each way we release (pypi, docker and @ichard26 did binaries) but due to my lack of access things have been going very slowly.

On a sad note, I'd like to echo I share @ichard26's frustration. I came to this project to help up the release cadence with adding primer, turning black into a module (from single file) and working on some other release blocks that have come up. It's been a little disheartening that our work just sits here and a lot of our issues stack up cause people are reporting issues that have been fixed! Once again, without @ichard26 we'd be in a crazy bad position issue wise. @ichard26's + @JelleZijlstra's work has been amazing!

That aside, I'd love to keep going. Can we please set/pin the remaining Issues + PR(s) we want merged for the last real stability bug and cut a release ASAP. Following this release lets please get straight to work on our refactor to break up our 7000+ line __init__.py and get a release out with that.

I'd also like to put my hand up to be the first BRMFN (Black Release Manger For Now). One of my first duties if I get this, will be to document the BRMFN role and a release schedule. Maybe we could call them BLEPs? (Bittorent uses BEPs)

[JelleZijlstra]

I agree with pretty much everything @cooperlees said, and I volunteer as an extra BRMFN. We got to keep this going and get releases out.

I'm not sure we need anything formal like a "BLEP"; the most important thing is just to get the releases out so that people get to use the new features we've been merging into Black. Adding more process might just make that harder.

[cooperlees]

I agree with pretty much everything @cooperlees said, and I volunteer as an extra BRMFN. We got to keep this going and get releases out.

I'm not sure we need anything formal like a "BLEP"; the most important thing is just to get the releases out so that people get to use the new features we've been merging into Black. Adding more process might just make that harder.

Anyone that knows me knows I hate formalities. I only wanted to do this if it helps things move again.

Once @ichard26 gets his docs refactor out I'll add documentation about the CI release workflows just so others can help with them etc. etc.

[ichard26]

Okay, back from a break and glad to see I'm not the only one feeling this way :)

Adding more process might just make that harder.

Yep, given the delays we've been facing, I'm hesitant to add more process. Policy or documentation to clear things up? Sure go for it, but other usages of process are too much for how little they could help.

Once @ichard26 gets his docs refactor out

Cool, I really need to finish that up don't I lol. One thing I haven't mentioned yet is that I initially wanted to get the documentation refactor merged right near a release since some of the links I added (part of the README rewrite) is requires the rest of the reorganized docs to be on the stable rev on RTD already. But I think I'll just skip doing the rewrites I planned to and do them later so I can get it merged to unblock stuff.

I'd also like to put my hand up to be the first BRMFN

I have no objections. For release day, I'll see if I can provide issue triage support (it's one of the things I'm good at) since oh boy this is going to be one rocky release with 8 months worth of changes :)

Finally, I haven't said this yet but @JelleZijlstra and @cooperlees I appreciate your work a lot, if it wasn't for you two I probably would've thrown in the towel by now.

[johnthagen]

Maybe @ambv has some time to delegate some more permissions? My understanding is that he's still the fundamental owner of black, right?

[ichard26]

Status update:

The major bug blocking this release (GH-1629) has been fixed by GH-2126 🎉

Right now we're in the process of testing and figuring out the last details of the release. Although I unfortunately don't have a timeline yet.

@cooperlees can provide more detail as our BRMFN (Black Release Manager For Now).

[cooperlees]

We haz a new version + whl file!

https://pypi.org/project/black/#files

🎉