Remove Beta marker, and increment major or minor version number

[mhsmith]

What is the problem or limitation you are having?

The pyproject.toml file still lists Briefcase as Development Status :: 4 - Beta. We should change this to Stable.

We've also been thinking of incrementing the version number to 0.4 to reflect the use of a virtual environment in briefcase dev. But maybe to reflect the development status, we should make it 1.0 instead?

[freakboy3742]

To be clear - briefcase dev doesn't use virtualenvs yet - but could very trivially do so now that #2420 has landed. #1735 is tracking that feature. That change has enough impact on UX that I think it's worth a version bump.

In terms of 1.0 - I agree that Briefcase is, broadly speaking, stable enough to warrant being tagged as such. However, there's a couple of features that would represent a non-trivial change to developer experience that I'd like to see resolved before we call Briefcase "fully stable":

• Implement persistent build tracking for more intuitive behavior #1714 (which is a resolution of cluster of issues, most notably Make create, update, build and run automatically execute any of the earlier steps which are out of date #807).
• A switch to using venvs for at least windows/macOS/iOS builds, inside an xbuild/xvenv environment.

The aim here isn't to make the software perfect - there's will always be issues to resolve. However, I'd like to nail down the things that represent significant source of UX friction in present workflows.

I'd also advocate that we'd move to calver, rather than a semver 1.0 (so, we'd go from 0.3.X/0.4.X to 25.X or 26.X, depending on when it happens).

[mhsmith]

• A switch to using venvs for at least windows/macOS/iOS builds, inside an xbuild/xvenv environment.

Why would Windows and macOS need a cross environment?

[freakboy3742]

Why would Windows and macOS need a cross environment?

Apologies - loose terminology on my part. macOS/Windows don't need a cross environment - but they would benefit from having pip run in a separate venv, so that dependency resolution isn't tainted by packages that are in the briefcase environment.

You can see this today if you have a development version of Toga installed in your briefcase venv, and then have toga==0.5.2 (or whatever) in your app's environment, you get warnings about how there's a dependency conflict. A clean "install for production" environment would prevent those conflicts.