I'm reconsidering the once-per-year schedule for stable releases.
Basically, a Postfix stable release freezes development at a point
in time, forever. Primarily, this is good for stability.
* In this day and age it seems archaic to have to wait for up to a
year before useful code can be deployed in a stable release.
* The once-per-year schedule makes development a race to get things
into the upcoming release, so that it does not have to wait for
another year.
There is a downside to less than a year between stable releases:
the support time window will become less than four years. Currently,
four stable releases are supported, and that is unlikely to change.
Examples of things that have been ready for months:
- TLS connection reuse without closing/reconnecting, a big deal for
sites that send many messages, completed in June 2018.
- BDAT support, requested by a provider, completed in August 2018.
Things that are ready in ~week, expected to be in Postfix 3.4.0:
- SNI support is feature and documentation complete. We are polishing
some externally-visible behavior such as message headers and logging.
- Logging to file or stdout, to work around crippled infrastructure
(MacOS, systemd), or to make Postfix play nice with containers.
This interrupted my work on BURL support (see below).
Things that we're racing to implement, so that they would not have
to wait until 2020:
- OpenSSL configuration file support.
- BURL (submit email without downloading content from IMAP server
first). Reuses most of the BDAT code.
- And so on.
A higher release frequency would help to get good code out the door
without having to race against a once-per-year schedule. But, as
mentioned, it also reduces the length of time that a given release
will be supported.
Wietse
