Planning uwsgi 2.1

[methane]

To stop the effort of maintaining two branches, 2.0 and master, would you consider releasing 2.1?

• Delete uwsgi-3.0 branch to avoid confusion.
• Drop Python 2 support.
• Use pyproject.toml.
• After 2.1 is released, only security fixes will be backported to 2.0 branch.
• Keep using master branch for 2.1 series for now, until we start working on 2.2.

[methane]

Drop many PoC and legacy plugins:

• v8
• tornado
• mono
• ruby19
• stackless
• objc-gc
• jvm
• jwsgi

[niol]

I think uwsgi is in maintenance mode and that either 2.0 or master (2.1?) should be selected to be the maintenance branch, to avoid the hassle of cherry-picking fixes (and forgetting some others) to 2.0. From what I've seen in the last few years, there is not much happening in uwsgi regarding new features/major changes/versions. But that may change, who knows? I'm personally quite happy to still use it as it is.
Regarding plugins, I agree some could be dropped because they do not work anymore. On the contrary jvm, jwsgi still work (see CI with a Hello world app tested). I do not know if they are much used though.

[methane]

• Use pyproject.toml.

There are three setup.py now. setup.py, setup.cpyext.py, and setup.pyuwsgi.py.
Is setup.cpyext is used at all?

[jer0007]

What's the progress on this? This package will be effectively unusable with newer versions of pip in a couple months unless it's switched to pyproject.toml.

[csvance]

Since uwsgi is built with setuptools wouldn't a simple pyproject.toml with a block like this work:

[build-system]
requires = ["setuptools>=XX.X"]
build-backend = "setuptools.build_meta"

I just recently moved over one of my own setuptools projects to pyproject.toml like this and its building just fine with no other changes required.

[methane]

@csvance Does it work for Python 2?
If no, uwsgi should drop Python 2 in uwsgi-2.0 or uwsgi-2.1.
Thats why this issue is "just add simple pyproject.toml".