Rethinking the Postfix release schedule

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Rethinking the Postfix release schedule

Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Sven Schwedas
On 29.01.19 16:40, Wietse Venema wrote:
> 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.

IMO not much of a problem, the usual LTS distributions will offer longer
support cycles for those that really need it anyway (for varying values
of "support").


signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Ralph Seichter
In reply to this post by Wietse Venema
* Wietse Venema:

> There is a downside to less than a year between stable releases:
> the support time window will become less than four years.

Personally, I consider Postfix to be among the software packages which
are easiest to update (and I build from the sources, since early 2.5.x)
because of the outstanding quality. No server of mine or my customers is
using four-year-old Postfix versions. From my point of view, a shorter
support period is fully acceptable, especially if it means getting
useful changes released earlier.

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Scott Kitterman-4
In reply to this post by Wietse Venema
On Tuesday, January 29, 2019 10:40:37 AM Wietse Venema wrote:

> 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.

From my perspective as the primary packager for Debian, I think a faster
release cycle would possibly have very little impact on us, it mostly depends
how much faster.  Currently you are supporting releases a bit longer than we
need.

If you switch to a new release every 9 months, I don't think that would impact
us significantly.  If you switch to every 6 months, then I would start to
worry about supporting Debian stable users properly.

Would you consider doing limited support (security fixes only perhaps) for an
additional release or two?  If so, then I would think even 6 months wouldn't
hurt us.  It would definitely help with the problem of our freeze schedule
being slightly behind the postfix release schedule, so we just miss the newest
version.

Scott K


Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Daniel L. Miller
In reply to this post by Wietse Venema
On 1/29/2019 7:40 AM, Wietse Venema wrote:
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.


Are the reasons you imposed a once-per-year release previously lessened in some way today? The release schedule is far less important than the quality & usability of the product.  So the question is what works for you - and what will encourage you to continue making your efforts available to others?

As a user - I'd prefer releases "when they're ready" regardless of timeline or age.  Postfix has the unfortunately unusual record of extreme stability - so as far as I'm concerned if you and those you work with consider a particular revision "stable-worthy" I'd rather you release it instead of waiting an arbitrary time period.  Which/how many versions you choose to provide support for is far less important to *me* than seeing continued growth.

But knowing that Postfix enjoys a preferred role for many distributions as the SMTP solution of choice I'm assuming you're also concerned about interactions with distro maintainers. So I suggest two possibilities:

1.  Similar to Ubuntu - have more frequent "short-term support" releases with designated "long-term support" releases at longer intervals.

2.  Re-consider whether arbitrary date-based releases are meaningful at all.  Instead, release on the "when they're ready" model and when a combination of reporting frequency and your own sensibilities tell you conditions are right designate a particular release as "long-term stable" - which will probably be close to an annual basis and will hopefully line-up with most distro freeze schedules as well.


--
Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Wietse Venema
Daniel Miller:

> On 1/29/2019 7:40 AM, Wietse Venema wrote:
> > 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.
> >
> Are the reasons you imposed a once-per-year release previously lessened
> in some way today? The release schedule is far less important than the
> quality & usability of the product.? So the question is what works for
> you - and what will encourage you to continue making your efforts
> available to others?

Mainly, I don't want to race to get code ready for the once-per-year
release, and I don't want to wait for an entire year if the code
is not ready before the deadline.

I indent to keep using non-stable (dated) releases for code that I
can still change, because that works best for me.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Andrey Repin-2
In reply to this post by Wietse Venema
Greetings, Wietse Venema!

> 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.

Reading your message, I only see a call for speakers.
But I have a doubt you did not consider existing development schedules of
other projects and how would they fit into your vision of your project.

Well, lets talk about it.

Given project maturity, it's a negligible chance that something fundamental,
like config file parsing, would be changed.
So, that leaves us with
1. New functionality.
2. New features.
3. Changes in existing feature set.
4. Changes in existing functionality.

#4 seems negligible as well, as postfix rely upon existing standards.

Now, what about long-term supported releases? They are useful for enterprises
which could rely on a stable feature set for their dependent needs/services.
But they also stall development somewhat.

Different projects handle this issue differently.

PHP is extremely backward compatible. The code written for PHP3 can be run on
PHP7 with minimal, if any, changes. At the same time they are maintaining 2-3
versions in parallel when something serious is changed intenrally that
warrants the split.

LXC supports dual development model, they have a dedicated LTS release
version, where no major changes are happening, and a mainline non-LTS version,
which picks up all feature-complete innovations.

So, what do you think would suit your project?


--
With best regards,
Andrey Repin
Wednesday, January 30, 2019 22:00:26

Sorry for my terrible english...

Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Yuval Levy
In reply to this post by Wietse Venema
> Mainly, I don't want to race to get code ready for the once-per-year
> release, and I don't want to wait for an entire year if the code
> is not ready before the deadline.

Release any time a sufficiently important feature is ready and do not
let any schedule pressure force you to compromise on quality.

Support the last two (or however many you want) releases, with support
window dictated by the release process, relatively unpredictable but
still reasonably acceptable for those of us who build from source.

Once in a while, tag a release LTS and support it for a period that
makes distributors happy (four years?).  That once in a while could be
narrowed down as "once every half of the defined LTS support period" to
make sure that you do not have to support more than four releases total,
keeping the support obligation the same as today.  It could also be
synchronized with the timing of your major distributors to match their
schedules.

Yuv's 2 cents
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Wietse Venema
In reply to this post by Andrey Repin-2
I do not care much what other projects do. Postfix has a good record
for quality, stability and compatibility, and it supports four
stable releases, each release receiving updates for four years.

I do observe that 1) several major features were ready about 6
months after the 3.3 stable release that would have solved a real
problem; and 2) I have code that is not ready for the 3.4 release,
but I don't want to wait with until 2020. Both problems can be
solved with a less-than-year release cycle.

So that is what I plan to do.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Wietse Venema
In reply to this post by Yuval Levy
One problem with LTS releases is that down-stream distros can end
up running very old code (for example with 4-year LTS up-stream,
a down-stream distro with 4-year LTS can end up running 8-year old
code, which is really a pain to support on a mailing list like this
one). SMTP may be an old protocol but even there, a lot changes in
four years.

Since I don't control when a downstream distro's LTS clock starts
ticking, I'll stick with a handful supported stable releases.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Patrick Ben Koetter-2
In reply to this post by Wietse Venema
* Wietse Venema <[hidden email]>:
> I do not care much what other projects do. Postfix has a good record
> for quality, stability and compatibility, and it supports four
> stable releases, each release receiving updates for four years.
>
> I do observe that 1) several major features were ready about 6
> months after the 3.3 stable release that would have solved a real
> problem; and 2) I have code that is not ready for the 3.4 release,
> but I don't want to wait with until 2020. Both problems can be
> solved with a less-than-year release cycle.

Why wait for a group of features before a release? Why not release per
feature?

p@rick

--
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Viktor Dukhovni
> On Jan 30, 2019, at 4:39 PM, Patrick Ben Koetter <[hidden email]> wrote:
>
> Why wait for a group of features before a release? Why not release per
> feature?

Because people want a reasonable period of support for released code.
And we can only support a small handful of releases.  So increasing the
release cadence to two per year would limit the bugfix lifetime of each
release to 2 years instead of four.

I think a compromise is that we should be free to release major features
at any six month boundary, but June/July releases would be skipped if
we had nothing major in the pipeline.  That way we'd have up-to 2 releases
per year, but perhaps still have only one release per year some of the time.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Richard Damon
On 1/30/19 4:45 PM, Viktor Dukhovni wrote:

>> On Jan 30, 2019, at 4:39 PM, Patrick Ben Koetter <[hidden email]> wrote:
>>
>> Why wait for a group of features before a release? Why not release per
>> feature?
> Because people want a reasonable period of support for released code.
> And we can only support a small handful of releases.  So increasing the
> release cadence to two per year would limit the bugfix lifetime of each
> release to 2 years instead of four.
>
> I think a compromise is that we should be free to release major features
> at any six month boundary, but June/July releases would be skipped if
> we had nothing major in the pipeline.  That way we'd have up-to 2 releases
> per year, but perhaps still have only one release per year some of the time.
>
Another option would be to designate certain releases as 'LTS', which
would have support for a given number of years, and others have more
limited support (like for only a limited time after any subsequent
release). Make only 1 LTS per year, and then you have 3 years from 3 LTS
releases + 1 most current release.

--
Richard Damon

Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Matus UHLAR - fantomas
In reply to this post by Wietse Venema
On 30.01.19 16:38, Wietse Venema wrote:
>One problem with LTS releases is that down-stream distros can end
>up running very old code (for example with 4-year LTS up-stream,
>a down-stream distro with 4-year LTS can end up running 8-year old
>code, which is really a pain to support on a mailing list like this
>one). SMTP may be an old protocol but even there, a lot changes in
>four years.

wouldn't e.g. reducing to one current and 2 LTS releases make this easier?

commercial distros like redhat can support LTS releases on their own, while
debian and ubuntu LTS have 2-year cycle and 5-year LTS support, yes, that
can get near 8 years behind.

otoh, it may be acceptable to drop support if a release is very hard to
maintain

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I just got lost in thought. It was unfamiliar territory.
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Jim P.
On January 31, 2019 11:10:50 AM UTC, Matus UHLAR - fantomas <[hidden email]> wrote:
>while debian and ubuntu LTS have 2-year cycle and 5-year LTS support, yes,
>that can get near 8 years behind.


Debian has no strict release cycles, and Debian's LTS is based on several factors including $$, time, and personnel.

-Jim P.
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Postfix User-2
In reply to this post by Richard Damon
On Wed, 30 Jan 2019 21:14:07 -0500, Richard Damon stated:

<truncated>

FreeBSD users already have a choice of either the latest postfix
version, Postfix 3.3 stable release or the latest beta
version,Postfix 3.4 experimental release. I don't know if
there is a good reason to modify the release dates, at least not in my
case.

--
Postfix User



Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Matus UHLAR - fantomas
In reply to this post by Jim P.
>On January 31, 2019 11:10:50 AM UTC, Matus UHLAR - fantomas <[hidden email]> wrote:
>>while debian and ubuntu LTS have 2-year cycle and 5-year LTS support, yes,
>>that can get near 8 years behind.

On 31.01.19 11:22, Jim Popovitch wrote:
>Debian has no strict release cycles, and Debian's LTS is based on several
> factors including $$, time, and personnel.

while you are technically correct, last few releases match that estimate.
--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
42.7 percent of all statistics are made up on the spot.
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Andrey Repin-2
In reply to this post by Wietse Venema
Greetings, Wietse Venema!

> I do not care much what other projects do.

Did I say you do? I just outlined two most common approaches, with examples.

> Postfix has a good record for quality, stability and compatibility, and it
> supports four stable releases, each release receiving updates for four
> years.

Supporting FOUR releases, four years each… feels a bit heavy in my book.

> I do observe that 1) several major features were ready about 6
> months after the 3.3 stable release that would have solved a real
> problem; and 2) I have code that is not ready for the 3.4 release,
> but I don't want to wait with until 2020. Both problems can be
> solved with a less-than-year release cycle.

> So that is what I plan to do.

I though that the very plan to have an arbitrarily timed release schedule was
what you were feeling uncomfortable about.

It seems, I was mistaken.


--
With best regards,
Andrey Repin
Friday, February 1, 2019 2:56:40

Sorry for my terrible english...
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking the Postfix release schedule

Wietse Venema
Andrey Repin:
[ Charset windows-1250 converted... ]
> Greetings, Wietse Venema!
>
> > I do not care much what other projects do.
>
> Did I say you do? I just outlined two most common approaches, with examples.

Well, I don't like bringing up PHP in a discussion about Postfix :-(

> > Postfix has a good record for quality, stability and compatibility, and it
> > supports four stable releases, each release receiving updates for four
> > years.
>
> Supporting FOUR releases, four years each? feels a bit heavy in my book.

It has not been a problem, and it ensures that downstream LTS distros
won't be releasing unsupported Postfix versions.

> > I do observe that 1) several major features were ready about 6
> > months after the 3.3 stable release that would have solved a real
> > problem; and 2) I have code that is not ready for the 3.4 release,
> > but I don't want to wait with until 2020. Both problems can be
> > solved with a less-than-year release cycle.
>
> > So that is what I plan to do.
>
> I though that the very plan to have an arbitrarily timed release schedule was
> what you were feeling uncomfortable about.
>
> It seems, I was mistaken.

I agree that an arbitray schedule would be problematic.


        Wietse