What's on the table for 1.5.0?

[pepoluan]

So, what is on the table for 1.5.0? What will be planned to include/add/modify?

I'd like aiosmtpd to try to follow the guidelines of SemVer 2.0.0, namely these two:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

So in other words, if we release 1.5.0, we should NOT break any backwards compatibility, though we MAY add deprecation notices.

I figure that for 1.5.0 we can start 'modernizing' the asyncio plumbing within aiosmtpd to all the good stuff introduced in Python 3.7 and stop using <=3.6 boilerplates.

Note: I know that the statement "removal of Python 3.6 support" that accompanied 1.4.3 release was, technically, a declaration of backwards-compatibility-break. But practically, the code still runs on Python 3.6. As had been proven before PR #359 where the code runs without problems on PyPy3.6. So although we no longer support Python 3.6 after PR #359, backwards compatibility was actually still maintained. But when we start 'modernizing' asyncio within aiosmtpd, that's when backwards compatibility will be completely broken.

Note 2: However, despite 1.5.0 will likely break compat with 3.6, it probably does not deserve a major version bump to 2.0.0, because for users that use Python>=3.7, we will maintain API & behavior compatibility (to an extent). Meaning that 1.5.0 should be a drop-in replacement for 1.4.x line. But we can -- and probably have to -- start adding more DeprecationWarnings where necessary.

[waynew]

I used to be a fan of SemVer until I started learning how a good changelog should pretty much sort all that out anyway. But that's not really a change I feel any particular need to push here 😂

Anyway - yeah, dropping compatibility for unsupported versions of Python shouldn't require major or arguably even minor version bumps. Though obviously there will be other changes when that kind of change happens anyway.

After supporting Salt for a couple of years I've become a very strong proponent of dropping support for Python versions as soon as Python drops support for them 😂

[webknjaz]

@pepoluan I see you marked the last release only compatible with Python 3.7. This is problematic in terms of the forward compatibility. We've been cleaning up all the mentions of capping the top version in the Require-Python metadata field because people often don't realize the consequences of doing so...