Thread: Unclear EOL
Folks, The EOLs listed in the table aren't super specific looking forward. https://www.postgresql.org/support/versioning/ Would it be OK to name the (planned) release date of the final minor release in that table? I'm asking because I've had some complaints from people who assume, I believe reasonably, that that table represents the actual EOL and not the current meaning of, "the date past which the date of the next point release is planned to come out." What say? Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
> On Sep 5, 2018, at 14:37, David Fetter <david@fetter.org> wrote: > "the date past which the date of the next > point release is planned to come out." But that's not what EOL means, right? What the EOL date means is, "Past this date no further minor releases are anticipated." If people are confused by this now, they will be *very* confused by publishing a release date that may or maynot actually happen several years in the future. -- -- Christophe Pettus xof@thebuild.com
Folks,
The EOLs listed in the table aren't super specific looking forward.
https://www.postgresql.org/support/versioning/
Would it be OK to name the (planned) release date of the final minor
release in that table?
I'm asking because I've had some complaints from people who assume, I
believe reasonably, that that table represents the actual EOL and not
the current meaning of, "the date past which the date of the next
point release is planned to come out."
What say?
Maybe do:
Current: "After its end-of-life (EOL) month ends, a major version receives one final minor release. After that final minor release, bug fixing ceases for that major version."
Change that to read "After its end-of-life month (EOL Month) passes a major version receives one final minor release and no more bug fix patches will be written for it."
Then update the column header to read "EOL Month" instead of "EOL date"
I don't see a problem with people thinking they have roughly 4 fewer months (one less minor version) of support for their version than they really do if they mis-interpret the meaning of the month in the column. We are perfectly clear in the text as to our procedure.
David J.
P.S. Style-wise the words "minor", "release" and "date" should all be capitalized when used as column header titles.
P.P.S. The table could use splitting into supported and non-supported instead of simply using the yes/no to distinguish between the two. Its getting kind of long and the non-supported should not draw attention away from the list of supported releases.
On 09/05/2018 02:37 PM, David Fetter wrote: > Folks, > > The EOLs listed in the table aren't super specific looking forward. > > https://www.postgresql.org/support/versioning/ > > Would it be OK to name the (planned) release date of the final minor > release in that table? > > I'm asking because I've had some complaints from people who assume, I > believe reasonably, that that table represents the actual EOL and not > the current meaning of, "the date past which the date of the next > point release is planned to come out." I am not getting that. If you look at 10: Version Current minor Supported First release date EOL date 10 10.5 Yes October 2017 October 2022 EOL of life is at the 5 years support stated. At that point no further releases will be done on it. > > What say? > > Best, > David. > -- Adrian Klaver adrian.klaver@aklaver.com
On 09/05/2018 02:57 PM, Adrian Klaver wrote: > On 09/05/2018 02:37 PM, David Fetter wrote: >> Folks, >> >> The EOLs listed in the table aren't super specific looking forward. >> >> https://www.postgresql.org/support/versioning/ >> >> Would it be OK to name the (planned) release date of the final minor >> release in that table? >> >> I'm asking because I've had some complaints from people who assume, I >> believe reasonably, that that table represents the actual EOL and not >> the current meaning of, "the date past which the date of the next >> point release is planned to come out." > > I am not getting that. If you look at 10: > > Version Current minor Supported First release date EOL date > 10 10.5 Yes October 2017 October 2022 > > EOL of life is at the 5 years support stated. At that point no further > releases will be done on it. Hmm, read David J.'s post and learned something. There is one more minor release done. Still, I figure that the EOL date(month) is the one I ought to have upgraded by. > > >> >> What say? >> >> Best, >> David. >> > > -- Adrian Klaver adrian.klaver@aklaver.com
On 09/05/2018 02:37 PM, David Fetter wrote:Folks,
The EOLs listed in the table aren't super specific looking forward.
https://www.postgresql.org/support/versioning/
Would it be OK to name the (planned) release date of the final minor
release in that table?
I'm asking because I've had some complaints from people who assume, I
believe reasonably, that that table represents the actual EOL and not
the current meaning of, "the date past which the date of the next
point release is planned to come out."
I am not getting that. If you look at 10:
Version Current minor Supported First release date EOL date
10 10.5 Yes October 2017 October 2022
EOL of life is at the 5 years support stated. At that point no further releases will be done on it.
9.3:
September 2018Minor Releases:
November 8th, 2018
February 14th, 2019
May 9th, 2019
August 8th, 2019
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.
David J.
On 09/05/2018 03:04 PM, David G. Johnston wrote: > On Wed, Sep 5, 2018 at 2:57 PM, Adrian Klaver <adrian.klaver@aklaver.com > <mailto:adrian.klaver@aklaver.com>>wrote: > > On 09/05/2018 02:37 PM, David Fetter wrote: > > Folks, > > The EOLs listed in the table aren't super specific looking forward. > > https://www.postgresql.org/support/versioning/ > <https://www.postgresql.org/support/versioning/> > > Would it be OK to name the (planned) release date of the final minor > release in that table? > > I'm asking because I've had some complaints from people who > assume, I > believe reasonably, that that table represents the actual EOL > and not > the current meaning of, "the date past which the date of the next > point release is planned to come out." > > > I am not getting that. If you look at 10: > > Version Current minor Supported First release date EOL date > 10 10.5 Yes October 2017 October 2022 > > EOL of life is at the 5 years support stated. At that point no > further releases will be done on it. > > > 9.3: > September 2018 > > Minor Releases: > > November 8th, 2018 > February 14th, 2019 > May 9th, 2019 > August 8th, 2019 > > 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:) > > David J. > -- Adrian Klaver adrian.klaver@aklaver.com
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.
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.
regards, tom lane
On Wed, Sep 05, 2018 at 02:42:55PM -0700, Christophe Pettus wrote: > > > On Sep 5, 2018, at 14:37, David Fetter <david@fetter.org> wrote: > > "the date past which the date of the next > > point release is planned to come out." > > But that's not what EOL means, right? What the EOL date means is, > "Past this date no further minor releases are anticipated." If > people are confused by this now, they will be *very* confused by > publishing a release date that may or may not actually happen > several years in the future. That's an excellent point. I'm thinking we could supply only the dates in the past and, only when we know it, one date in the future, so something like: Version Current minor Supported First release date EOL month Last release date 10 10.5 Yes October 2017 October 2022 N/A 9.6 9.6.10 Yes September 2016 September 2021 N/A 9.5 9.5.14 Yes January 2016 January 2021 N/A 9.4 9.4.19 Yes December 2014 December 2019 N/A 9.3 9.3.24 Yes September 2013 September 2018 November 8, 2018 (tentative) 9.2 9.2.24 No September 2012 September 2017 November 9, 2017 ... Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
> That's an excellent point. I'm thinking we could supply only the dates
> in the past and, only when we know it, one date in the future, so
> something like:
> Version Current minor Supported First release date EOL month Last release date
> 10 10.5 Yes October 2017 October 2022 N/A
> 9.6 9.6.10 Yes September 2016 September 2021 N/A
> 9.5 9.5.14 Yes January 2016 January 2021 N/A
> 9.4 9.4.19 Yes December 2014 December 2019 N/A
> 9.3 9.3.24 Yes September 2013 September 2018 November 8, 2018 (tentative)
> 9.2 9.2.24 No September 2012 September 2017 November 9, 2017
> ...
What exactly is the point of that?
I think the main effect it would have is to encourage people to think
they'll continue to have support past the stated EOL month. That seems
counterproductive for all concerned.
regards, tom lane
On 9/5/18 3:25 PM, Tom Lane 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. > > 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. Applied above suggestions to the page, with a couple of other clarifying tweaks. Thanks, Jonathan
Attachment
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
Attachment
Stephen Frost <sfrost@snowman.net> writes:
> 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.
True, there used to be no planned release schedule at all.
> 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.
Seems reasonable to me. Maybe s/planned/scheduled/ for clarity.
regards, tom lane
On 09/09/2018 18:01, Tom Lane wrote: >> 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. > > Seems reasonable to me. Maybe s/planned/scheduled/ for clarity. So that would mean that if the EOL month is September and the next minor release is scheduled for November, but we do an unplanned release in October, we would then have to still support it until November? Or if we skip the November release, we have to keep going until February? I think a bit of ambiguity is good here. After the EOL month, you're on your own. We might do something afterwards for technical or bookkeeping reasons or because we think it's important, but don't count on it. Maybe in five years we'll be releasing a minor every three weeks, how do we adjust the policy then? Let's not over-specify this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 9/11/18 10:08 AM, Peter Eisentraut wrote: > On 09/09/2018 18:01, Tom Lane wrote: >>> 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. >> >> Seems reasonable to me. Maybe s/planned/scheduled/ for clarity. > > So that would mean that if the EOL month is September and the next minor > release is scheduled for November, but we do an unplanned release in > October, we would then have to still support it until November? Or if > we skip the November release, we have to keep going until February? > > I think a bit of ambiguity is good here. After the EOL month, you're on > your own. We might do something afterwards for technical or bookkeeping > reasons or because we think it's important, but don't count on it. > Maybe in five years we'll be releasing a minor every three weeks, how do > we adjust the policy then? Let's not over-specify this. +1. I think the first sentence in the "PostgreSQL Release Support Policy section clearly states what happens: "The PostgreSQL Global Development Group aims to support a major release for five years. After its end-of-life (EOL) month ends, a major version receives one final minor release. After that final minor release, bug fixing ceases for that major version." That said, maybe it's better to make that the first sentence on the page, as really that's the most important part. Details on how things are numbered, upgrades, etc. could go closer to the table. Thoughts? Jonathan
Attachment
Greetings, * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote: > On 09/09/2018 18:01, Tom Lane wrote: > >> 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. > > > > Seems reasonable to me. Maybe s/planned/scheduled/ for clarity. > > So that would mean that if the EOL month is September and the next minor > release is scheduled for November, but we do an unplanned release in > October, we would then have to still support it until November? Or if > we skip the November release, we have to keep going until February? Practically speaking, we would almost certainly either decide that the issue causing us to consider an October release can wait until November, or we would accept that it's important enough that we do an October release and then still do a November release anyway. That's what we did the last time around and it seems quite unlikely to me that we're going to just entirely skip a release in the future, given our published schedule. Should we ultimately decide to do that, we're already going to be changing what we've published as a schedule and so changing the schedule for EOL for that major version isn't all that different anyway. > I think a bit of ambiguity is good here. After the EOL month, you're on > your own. We might do something afterwards for technical or bookkeeping > reasons or because we think it's important, but don't count on it. > Maybe in five years we'll be releasing a minor every three weeks, how do > we adjust the policy then? Let's not over-specify this. I don't agree that ambiguity here is good, nor do I buy the argument that we should keep it ambiguous because we might change things in the future. If and when we change things in the future, I'd expect us to also be adjusting the EOL schedule, which seems entirely reasonable. Right now we're in a situation where we changed one and not the other, and that's causing confusion. Let's correct that by making them both explicit and clear. Thanks! Stephen
Attachment
Greetings, * Jonathan S. Katz (jkatz@postgresql.org) wrote: > On 9/11/18 10:08 AM, Peter Eisentraut wrote: > > So that would mean that if the EOL month is September and the next minor > > release is scheduled for November, but we do an unplanned release in > > October, we would then have to still support it until November? Or if > > we skip the November release, we have to keep going until February? > > > > I think a bit of ambiguity is good here. After the EOL month, you're on > > your own. We might do something afterwards for technical or bookkeeping > > reasons or because we think it's important, but don't count on it. > > Maybe in five years we'll be releasing a minor every three weeks, how do > > we adjust the policy then? Let's not over-specify this. > > +1. I think the first sentence in the "PostgreSQL Release Support Policy > section clearly states what happens: > > "The PostgreSQL Global Development Group aims to support a major release > for five years. After its end-of-life (EOL) month ends, a major version > receives one final minor release. After that final minor release, bug > fixing ceases for that major version." Yes, that's what it says, but I don't agree that it's clear at all. That's exactly what started this thread. > That said, maybe it's better to make that the first sentence on the > page, as really that's the most important part. Details on how things > are numbered, upgrades, etc. could go closer to the table. A big block of text above a table which contains the actual information people are looking for is just going to get ignored until someone explicitly points out that "well, this is what the policy says".. and then further explains it, because it's really rather confusing. We all get it and understand it because we've been around it for a very long time and are familiar with it. Thanks! Stephen
Attachment
On 9/11/18 10:22 AM, Stephen Frost wrote: > Greetings, > > * Jonathan S. Katz (jkatz@postgresql.org) wrote: >> On 9/11/18 10:08 AM, Peter Eisentraut wrote: >>> So that would mean that if the EOL month is September and the next minor >>> release is scheduled for November, but we do an unplanned release in >>> October, we would then have to still support it until November? Or if >>> we skip the November release, we have to keep going until February? >>> >>> I think a bit of ambiguity is good here. After the EOL month, you're on >>> your own. We might do something afterwards for technical or bookkeeping >>> reasons or because we think it's important, but don't count on it. >>> Maybe in five years we'll be releasing a minor every three weeks, how do >>> we adjust the policy then? Let's not over-specify this. >> >> +1. I think the first sentence in the "PostgreSQL Release Support Policy >> section clearly states what happens: >> >> "The PostgreSQL Global Development Group aims to support a major release >> for five years. After its end-of-life (EOL) month ends, a major version >> receives one final minor release. After that final minor release, bug >> fixing ceases for that major version." > > Yes, that's what it says, but I don't agree that it's clear at all. > That's exactly what started this thread. After doing some spot user testing on the language, I will come around and say "yes, it's unclear." >> That said, maybe it's better to make that the first sentence on the >> page, as really that's the most important part. Details on how things >> are numbered, upgrades, etc. could go closer to the table. > > A big block of text above a table which contains the actual information > people are looking for is just going to get ignored until someone > explicitly points out that "well, this is what the policy says".. and > then further explains it, because it's really rather confusing. We all > get it and understand it because we've been around it for a very long > time and are familiar with it. I think we are saying similar things though...the content of the page needs some hierarchical restructuring, and yes, I'm convinced of some language cleanups as well. To make it more tangible, I'm happy to propose a patch in a few. Jonathan
Attachment
Greetings, * Jonathan S. Katz (jkatz@postgresql.org) wrote: > I think we are saying similar things though...the content of the page > needs some hierarchical restructuring, and yes, I'm convinced of some > language cleanups as well. > > To make it more tangible, I'm happy to propose a patch in a few. The point I was getting at is that we don't just need a patch here- our current EOL policy is really quite vague and confusing. Trying to reword that confusing and vague policy doesn't change that it's confusing and vague- to deal with that, we need to actually change the policy, which is what I'm advocating for here. Thanks! Stephen
Attachment
On 9/11/18 10:39 AM, Stephen Frost wrote: > Greetings, > > * Jonathan S. Katz (jkatz@postgresql.org) wrote: >> I think we are saying similar things though...the content of the page >> needs some hierarchical restructuring, and yes, I'm convinced of some >> language cleanups as well. >> >> To make it more tangible, I'm happy to propose a patch in a few. > > The point I was getting at is that we don't just need a patch here- our > current EOL policy is really quite vague and confusing. Trying to > reword that confusing and vague policy doesn't change that it's > confusing and vague- to deal with that, we need to actually change the > policy, which is what I'm advocating for here. We're saying the same thing. I just wanted to have something in writing so it's more tangible and easier to discuss. Thanks, Jonathan
Attachment
On 9/11/18 10:52 AM, Jonathan S. Katz wrote: > On 9/11/18 10:39 AM, Stephen Frost wrote: >> Greetings, >> >> * Jonathan S. Katz (jkatz@postgresql.org) wrote: >>> I think we are saying similar things though...the content of the page >>> needs some hierarchical restructuring, and yes, I'm convinced of some >>> language cleanups as well. >>> >>> To make it more tangible, I'm happy to propose a patch in a few. >> >> The point I was getting at is that we don't just need a patch here- our >> current EOL policy is really quite vague and confusing. Trying to >> reword that confusing and vague policy doesn't change that it's >> confusing and vague- to deal with that, we need to actually change the >> policy, which is what I'm advocating for here. > > We're saying the same thing. I just wanted to have something in writing > so it's more tangible and easier to discuss. Please see attached patch the includes the wording updates. The one thing that is not included is making "EOL Month" => "Expected Last Release" - currently this is set dynamically by "core.Version.eoldate" AFAICT this is only used in one place, on this page, and perhaps we can re-purpose it to reflect "Expected Last Release" Otherwise, I'd recommend a new column that contains the expected last release month. Thanks, Jonathan
Attachment
On Wed, Sep 12, 2018 at 7:51 PM, Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 9/11/18 10:52 AM, Jonathan S. Katz wrote:
> On 9/11/18 10:39 AM, Stephen Frost wrote:
>> Greetings,
>>
>> * Jonathan S. Katz (jkatz@postgresql.org) wrote:
>>> I think we are saying similar things though...the content of the page
>>> needs some hierarchical restructuring, and yes, I'm convinced of some
>>> language cleanups as well.
>>>
>>> To make it more tangible, I'm happy to propose a patch in a few.
>>
>> The point I was getting at is that we don't just need a patch here- our
>> current EOL policy is really quite vague and confusing. Trying to
>> reword that confusing and vague policy doesn't change that it's
>> confusing and vague- to deal with that, we need to actually change the
>> policy, which is what I'm advocating for here.
>
> We're saying the same thing. I just wanted to have something in writing
> so it's more tangible and easier to discuss.
Please see attached patch the includes the wording updates.
+The PostgreSQL Global Development Group releases a new major version containing
+new features about once a year. Each major version receives bug fixes and, if
+need be, <a href="/support/security/">security</a> fixes that are released every three months in what we call a
+"minor release." For more information on the minor release schedule, you can
+view the <a href="/developer/roadmap/">minor release roadmap</a>.
That needs to be "at least every three months". We sometimes release more often.
The one thing that is not included is making "EOL Month" => "Expected
Last Release" - currently this is set dynamically by "core.Version.eoldate"
AFAICT this is only used in one place, on this page, and perhaps we can
re-purpose it to reflect "Expected Last Release"
Yes, that's the only thing it's used for. So you should be able to keep using that one, just stop truncating the output to month level in the template.
//Magnus
On 9/18/18 11:18 AM, Magnus Hagander wrote: > > +The PostgreSQL Global Development Group releases a new major version > containing > +new features about once a year. Each major version receives bug fixes > and, if > +need be, <a href="/support/security/">security</a> fixes that are > released every three months in what we call a > +"minor release." For more information on the minor release schedule, > you can > +view the <a href="/developer/roadmap/">minor release roadmap</a>. > > > That needs to be "at least every three months". We sometimes release > more often. > > > > > The one thing that is not included is making "EOL Month" => "Expected > Last Release" - currently this is set dynamically by > "core.Version.eoldate" > > AFAICT this is only used in one place, on this page, and perhaps we can > re-purpose it to reflect "Expected Last Release" > > > Yes, that's the only thing it's used for. So you should be able to keep > using that one, just stop truncating the output to month level in the > template. Thanks for the feedback. I have pushed the patch. Jonathan
Attachment
Greetings, * Jonathan S. Katz (jkatz@postgresql.org) wrote: > On 9/18/18 11:18 AM, Magnus Hagander wrote: > > +The PostgreSQL Global Development Group releases a new major version > > containing > > +new features about once a year. Each major version receives bug fixes > > and, if > > +need be, <a href="/support/security/">security</a> fixes that are > > released every three months in what we call a > > +"minor release." For more information on the minor release schedule, > > you can > > +view the <a href="/developer/roadmap/">minor release roadmap</a>. > > > > That needs to be "at least every three months". We sometimes release > > more often. Right. > > The one thing that is not included is making "EOL Month" => "Expected > > Last Release" - currently this is set dynamically by > > "core.Version.eoldate" > > > > AFAICT this is only used in one place, on this page, and perhaps we can > > re-purpose it to reflect "Expected Last Release" > > > > Yes, that's the only thing it's used for. So you should be able to keep > > using that one, just stop truncating the output to month level in the > > template. > > Thanks for the feedback. I have pushed the patch. Thanks for working on this Jonathan, but I'm not sure that saying "Expected Final Release" really changes things. For one thing, having "Expected Final Release" dates in the past is pretty confusing. For another, as we've just gone over in some detail, we've agreed to a release schedule for minor releases and therefore it's sufficient to just say "Final Release". If we really want to add some words to that, we could do so above the table. I'd also change "RELEASE HISTORY" to be something more like "RELEASES" since it's talking about the future too, not just history. Thanks! Stephen
Attachment
Hi Stephen, On 9/18/18 6:08 PM, Stephen Frost wrote: > > Thanks for working on this Jonathan, but I'm not sure that saying > "Expected Final Release" really changes things. For one thing, having > "Expected Final Release" dates in the past is pretty confusing. For > another, as we've just gone over in some detail, we've agreed to a > release schedule for minor releases and therefore it's sufficient to > just say "Final Release". If we really want to add some words to that, > we could do so above the table. > > I'd also change "RELEASE HISTORY" to be something more like "RELEASES" > since it's talking about the future too, not just history. Thanks for the suggestions. I have made the changes. Thanks, Jonathan