Stop saying mypy is beta software?

[msullivan]

We're tagged as alpha in pypi and in our readme we say "Mypy is alpha software, but it has already been used in production for well over a year at Dropbox, and it has an extensive test suite."

While mypy certainly has its flaws I, I think it is pretty well established that it is usable in a serious way, and in fact we pretty seriously recommend it as such.

EDIT (by Ethan): We now say we are beta, should we say we are production ready?

[ilevkivskyi]

I think we can call it beta. Some people define beta when software is feature-complete w.r.t. subsequent major release, but IIUC this is rather a tradition than a specification.

[gvanrossum]

We're being very self-deprecating here. I would not hesitate calling mypy production quality, i.e. beyond beta.

[emmatyping]

I agree at minimum that mypy is beta quality, if not better. When adding mypy typing to a project recently, a friend was surprised mypy hasn't hit 1.0 yet! I do think we should explain that backwards incompatible changes may still happen, but we try not to do so?

[Michael0x2a]

It'd be nice if we could align the announcement that mypy is now production-quality with a somewhat impressive release. Maybe we should just silently switch over to calling ourselves "beta" for now and wait one or two releases before announcing that mypy is production-quality/that we're releasing v1.0? We could perhaps combine that announcement with the "we have a new semantic analyzer" release or something.

This is only a suggestion though -- I don't really have a strong opinion on this apart from agreeing that we're definitely past the alpha stage.

[JukkaL]

@Michael0x2a I like your idea!

[wasilukm]

Hi, could you please consider also switching to semantic versioning?

[emmatyping]

@wasilukm AIUI the plan is to switch to semver at 1.0. So if we go ahead with @Michael0x2a's proposal that will be in a couple of releases.

With regards to Michael's plan, my only concern is that the new semantic analyzer should probably be battle tested for a couple of releases, as I worry we'd release 1.0 then have several bugs crop up, which would weaken the stability message of a 1.0.

[JukkaL]

Applying semantic versioning is not trivial, since we'd need to document what the public API of mypy is. The command-line interface is well documented, but it's not clear which APIs plugins can safely depend on.

Even with semantic versioning, there would likely be no guarantees about new non-major version of mypy not generating extra errors, since many bug fixes, features and stub updates focus on turning false negatives into errors (and these changes may sometimes also cause false positives).

[gvanrossum]

Let’s at least call it beta everywhere.

I agree that the definition of semver will always be problematic.

So as an alternative to semver we could number releases by date, i.e. calver.