Re: Unclear EOL - Mailing list pgsql-www

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Adrian Klaver <adrian.klaver@aklaver.com> writes:
> > On 09/05/2018 03:04 PM, David G. Johnston wrote:
> >> The point is that 9.3 supposedly goes out of support in November 2018
> >> but the EOL Month is September, two months earlier.  If it truly ended
> >> in September the August release we just made would be the final one.
> >> But now that its September the next one is final but won't happen for 2
> >> months.
>
> > Yeah, I missed that on the versioning page. The thing is that the minor
> > release schedule is a suggestion that can be broken for security/severe
> > bug reasons. Counting on a fixed period after the EOL month is sort of
> > liking counting on stoppage time in football(soccer) to be a known value
> > ahead of time. I for one would not put money on it:)
>
> Right, it would be a mistake to modify this table on the basis of the
> current schedule for minor releases.  Given the policy explanation above
> the table, I think it's fine as-is ... though I agree with David that
> the column heading should be "EOL month" not "EOL date", because "EOL
> month" is the term used in the explanation.

Perhaps what we should be considering at this point is if the project's
EOL policy should be changed, based, in part, on the fact that we've
changed our minor release policy.  As some may recall, we didn't always
have specific dates listed for minor releases either.

As for a specific suggestion, I would amend our current policy to state
that we support each major version for 5 years, with the last release of
a given major version being the planned minor release following the 5
year mark.

That's a change from our current policy where we would drop support for
a given major release as of the next minor release (planned or
unplanned) following the 5 year mark, however, practically speaking I
don't think we end up with much of a difference.  Yes, we do
out-of-cycle releases in certain cases, but they're pretty rare and even
in those cases we've (at least recently) ended up just having our
regular releases as well as the out-of-cycle release, which is the level
we were planning to support the given major release until anyway.

Overall, I think we're better for having a well defined minor release
policy that people can easily understand and plan around, and having a
similar clear-and-specific policy for EOL would also be good.

This isn't the list to decide such a policy change, of course, but
there's not much point bringing it up to the broader group unless the
folks on this thread think this is a reasonable change to consider, so
let's start here.

> Personally I'd also s/full support/support/ in the second para, because
> it gives the impression that we have more than one level of "support"
> for back branches.  We don't.

Independently of the above, I agree with changing 'full support' to
'support'.

Thanks!

Stephen