Thread: Do we really need a 7.4.22 release now?
I went through the CVS logs to draft release notes, and found that the list of patches applied to REL7_4_STABLE is a bit skimpy: http://developer.postgresql.org/pgdocs/postgres/release-7-4-22.html I'm wondering if we should leave 7.4 out of the current set of update releases. If I were a DBA conservative enough to still be runnng 7.4.x, I doubt I'd find anything there compelling enough to justify an upgrade. So I'm thinking that generating a 7.4.x tarball now would be mostly a waste of server space, and we should leave these changes for the next update cycle. The main counter-argument I can think of is that it's too confusing to release the same fixes in different branches at different times. We did that this spring, and it was confusing, at least when it came time to make the release notes for the next set of updates. But I dunno if any users noticed particularly. One thing that ties into this is whether there ever will *be* another 7.4.x release. We haven't formally discussed an EOL date for 7.4, but its fifth birthday will be 2008-11-17. I imagine we'd want to make its final update release be after that date. If we do a release now, the final update might be even skimpier than this one. Comments? regards, tom lane
Tom Lane wrote: > I went through the CVS logs to draft release notes, and found that the > list of patches applied to REL7_4_STABLE is a bit skimpy: > http://developer.postgresql.org/pgdocs/postgres/release-7-4-22.html > One thing that ties into this is whether there ever will *be* another > 7.4.x release. We haven't formally discussed an EOL date for 7.4, > but its fifth birthday will be 2008-11-17. I imagine we'd want to make > its final update release be after that date. If we do a release now, > the final update might be even skimpier than this one. > > Comments? IMO, we release 7.4.22 with the rest and it is also announced that as of 12-31-08 7.4.x is no more. Joshua D. Drake > > regards, tom lane >
On Thu, Sep 18, 2008 at 2:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > One thing that ties into this is whether there ever will *be* another > 7.4.x release. We haven't formally discussed an EOL date for 7.4, > but its fifth birthday will be 2008-11-17. I imagine we'd want to make > its final update release be after that date. If we do a release now, > the final update might be even skimpier than this one. I'd be in favour of EOL'ing it after a single final release late November/December (or whenever we do 8.3.5). -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> Comments? > IMO, we release 7.4.22 with the rest and it is also announced that as of > 12-31-08 7.4.x is no more. I'm all for killing 7.4, but that's a rather short time frame, especially as this is a busy time of year for many businesses. How about we make it further in the future (perhaps 2009-07-01, six months into the next year), and announce the change far and wide? - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200809180939 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkjSWjAACgkQvJuQZxSWSsg4OACggkx2PNYoWxC2Cmxx6wUy0X2b BjsAn3wMtU6nEklw5exl7DM0wsTNF6Rp =2Zak -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > >>> Comments? > >> IMO, we release 7.4.22 with the rest and it is also announced that as of >> 12-31-08 7.4.x is no more. > > I'm all for killing 7.4, but that's a rather short time frame, especially as > this is a busy time of year for many businesses. How about we make it further > in the future (perhaps 2009-07-01, six months into the next year), and announce > the change far and wide? I believe a single quarter gap is plenty in consideration of the age. It isn't like 7.4 isn't already really old. If this was 8.0 I would agree. Joshua D. Drake
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Greg Sabino Mullane wrote:
>> I'm all for killing 7.4, but that's a rather short time frame, especially as
>> this is a busy time of year for many businesses. How about we make it further
>> in the future (perhaps 2009-07-01, six months into the next year), and announce
>> the change far and wide?
> I believe a single quarter gap is plenty in consideration of the age. It
> isn't like 7.4 isn't already really old. If this was 8.0 I would agree.
The handwriting has been on the wall for 7.4 ever since we agreed that
7.3 would be EOL'd at five years...
I wasn't intending to start a discussion about how/when to EOL 7.4,
but since the thread has gone in that direction: my vote would be to
announce now (say, with the announcement of this set of releases) that
7.4 will be EOL'd with our first set of updates in 2009. That would
probably be the next update after this one, maybe two updates away
if we find any really serious bugs in the next month or two.
It's not like people have to stop using it the moment we do our
last release.
regards, tom lane
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> Greg Sabino Mullane wrote: >>> I'm all for killing 7.4, but that's a rather short time frame, especially as >>> this is a busy time of year for many businesses. How about we make it further >>> in the future (perhaps 2009-07-01, six months into the next year), and announce >>> the change far and wide? > >> I believe a single quarter gap is plenty in consideration of the age. It >> isn't like 7.4 isn't already really old. If this was 8.0 I would agree. > > The handwriting has been on the wall for 7.4 ever since we agreed that > 7.3 would be EOL'd at five years... > > I wasn't intending to start a discussion about how/when to EOL 7.4, > but since the thread has gone in that direction: my vote would be to > announce now (say, with the announcement of this set of releases) that > 7.4 will be EOL'd with our first set of updates in 2009. That would > probably be the next update after this one, maybe two updates away > if we find any really serious bugs in the next month or two. While I agree with the principle, I think the people who care about such things would need a date, and not just "whenever we do an update". This could be Jan 2nd or Dec 29th for all they know. I think it's better to set a date, and then we can push out a final 7.4 release on that day if there are any accumulated changes. //Magnus
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > The handwriting has been on the wall for 7.4 ever since we agreed that > 7.3 would be EOL'd at five years... "Handwriting on the wall" is entirely unrelated to an offical, published end of life date. > It's not like people have to stop using it the moment we do our > last release. No, but if we are going to stop releasing revisions with critical bugfixes, it is important that people know well in advance and can plan a migration to a supported version. Frankly, the whole pg_dump mess is what keeps many people on older versions, somtimes including 7.4. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200809181123 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkjScrkACgkQvJuQZxSWSshnKACg1+QxldUo8fHX/ULeDkWwclCh SpkAoKkN6tOclSqWl3YIGTpfDRMoINNh =Anux -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: > No, but if we are going to stop releasing revisions with critical bugfixes, > it is important that people know well in advance and can plan a migration > to a supported version. > > Frankly, the whole pg_dump mess is what keeps many people on older versions, > somtimes including 7.4. Sure but that was fixed, four years ago. At some point you recognize laziness and ineptness over caution and responsibility. Sincerely, Joshua D. Drake
On Thu, Sep 18, 2008 at 03:25:10PM -0000, Greg Sabino Mullane wrote: > Frankly, the whole pg_dump mess is what keeps many people on older versions, > somtimes including 7.4. This isn't my experience. The reasons people stay on older releases are manifold. A -- Andrew Sullivan ajs@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> Frankly, the whole pg_dump mess is what keeps many people on older versions, >> somtimes including 7.4. > Sure but that was fixed, four years ago. At some point you recognize > laziness and ineptness over caution and responsibility. I think you misunderstand my "mess". I'm referring to the fact that the only way to upgrade between major versions is with pg_dump and reload, which really, really sucks for large databases. - From a business perspective, there has been no reason to go through the pain and downtime of an upgrade, as long as the PG project is releasing point revisions to the 7.4 branch. As I said, I'm all for getting people off 7.4, but it needs to be done with a definite date, and December is way too soon. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200809181205 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkjSfRYACgkQvJuQZxSWSsgcAgCeJi5t23JhHIOBHDRqXMYneJaW pKoAoPflQaE6G6HR4H0OAsCC1BWiMt9g =Tz0+ -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: > - From a business perspective, there has been no reason to go through the > pain and downtime of an upgrade, as long as the PG project is releasing > point revisions to the 7.4 branch. As I said, I'm all for getting people > off 7.4, but it needs to be done with a definite date, and December is > way too soon. Specifying an EOL date does not stop people from continuing to run 7.4. They can set their own time lines to get off the release. They can also pay someone to update the back branch if it is that important to them. December 31st is plenty of time. This isn't closed source where with the big O says no more updates, you are completely hosed. Sincerely, Joshua D. Drake
Hi, On Thu, 2008-09-18 at 09:20 -0400, Tom Lane wrote: > So I'm thinking that generating a 7.4.x tarball now would be mostly a > waste of server space, and we should leave these changes for the next > update cycle. How much server space or CPU cycles are we talking about? I bet it is less than the bytes we spent during this discussion. Only I will build binaries for 7.4, and you'll push an update for RHEL. My vote is announcing all releases together, including 7.4 . -- Devrim GÜNDÜZ, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org
On Sep 18, 2008, at 07:38, Tom Lane wrote: > I wasn't intending to start a discussion about how/when to EOL 7.4, > but since the thread has gone in that direction: my vote would be to > announce now (say, with the announcement of this set of releases) that > 7.4 will be EOL'd with our first set of updates in 2009. That would > probably be the next update after this one, maybe two updates away > if we find any really serious bugs in the next month or two. +1 Best, David
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Greg Sabino Mullane wrote:
>> - From a business perspective, there has been no reason to go through the
>> pain and downtime of an upgrade, as long as the PG project is releasing
>> point revisions to the 7.4 branch. As I said, I'm all for getting people
>> off 7.4, but it needs to be done with a definite date, and December is
>> way too soon.
> Specifying an EOL date does not stop people from continuing to run 7.4.
> They can set their own time lines to get off the release. They can also
> pay someone to update the back branch if it is that important to them.
Yeah. What this is about is how long the *community* supports 7.4
(for free, and at the cost of time that might be better spent on
development).
Looking at the CVS logs makes it pretty obvious that we've been
effectively partially desupporting 7.4, and even 8.0 and 8.1 to some
extent, for awhile now. There have been numerous patches that were not
carried all the way back because they would have needed major revisions
for the older branches --- not because the problem didn't exist in some
form or other back then. The community hasn't got the interest or
resources to create such patches, much less to QA them to the level
where a person too conservative to move off an old branch would think
the patches were safe.
It's really past time to make it clear to all concerned that if they
want continued bug fixes for 7.4, they'd better start paying somebody
to do it.
regards, tom lane
"Greg Sabino Mullane" <greg@turnstep.com> writes: > From a business perspective, there has been no reason to go through the > pain and downtime of an upgrade, as long as the PG project is releasing > point revisions to the 7.4 branch. As I said, I'm all for getting people > off 7.4, but it needs to be done with a definite date, and December is > way too soon. I don't understand this, as soon as we released 8.0 you could take that as advance warning that 7.4 was going to be desupported someday. So in that sense they've had four years warning that this time was coming. The fact that the date wasn't set in stone doesn't change their decision-making process. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
Tom Lane wrote: > > Yeah. What this is about is how long the *community* supports 7.4... > Perhaps the discussion should be more global (and ultimately save time on having this discussion again in the future). Decide on the policy, make official and make it obvious. The time I usually hear tossed around is 5 years. This is the same support period that Ubuntu uses for the long-term-support releases of their server version - the longest support period they offer. As a user, 5 years seems a reasonable support period for a core infrastructure component. Whatever time-period is chosen, I would make it obvious in a variety of places: The versioning policy (add something like "Major releases are supported through minor-release updates for a period of five years following initial release." to http://www.postgresql.org/support/versioning). The FAQ (add an end-of-life FAQ): http://www.postgresql.org/docs/faqs.FAQ.html All release notes: I.e. for 7.4: "Release date: 2003-11-17 End-of-life date: 2008-11-17", for 7.4.21: "Release date: 2008-06-12 End-of-life date 2008-11-17" Perhaps even as a comment at the start of the "installation" sections of the manual: "It is recommended to use the most recent release... Major releases are supported for..." Cheers, Steve
Steve Crawford wrote: > Tom Lane wrote: >> >> Yeah. What this is about is how long the *community* supports 7.4... Is there any way to poll the community and see how much people in the community care about 7.4 community support? It seems possible that most people with large important 7.4 systems either (a) have commercial support contracts anyway or (b) are capable of supporting it in-house, or (c) are secretly praying for an excuse to upgrade anyway.
On Thu, 18 Sep 2008 16:57:19 -0700 Ron Mayer <rm_pg@cheapcomplexdevices.com> wrote: > (c) are secretly praying for an excuse > to upgrade anyway. heh -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > It's really past time to make it clear to all concerned that if they > want continued bug fixes for 7.4, they'd better start paying somebody > to do it. I agree with this 100%, my only issue is with the method and timing of "making it clear". Until now, there has been zero indication from the release notes, the website, or the community that 7.4 will be soon unsupported. If we are going to announce that, we should be making the announcement fair (e.g. not December 2008) and loud (e.g. -announce, - -general, main page of postgresql.org, press release). - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200809191537 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkjT/3YACgkQvJuQZxSWSsgFDwCff7IQVYz2q7GvHZEio51XUoq1 bkYAnRF1mYj8+A3cVzb4WxYw7VG28uRR =VrxN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > I don't understand this, as soon as we released 8.0 you could take that as > advance warning that 7.4 was going to be desupported someday. So in that sense > they've had four years warning that this time was coming. The fact that the > date wasn't set in stone doesn't change their decision-making process. That's silly, why would they think that? We did not have a policy when 8.0 came out as to how long branches were supported, nor was there any way to gauge how often releases were coming out. Should people on 8.2 have been thinking the same thing about 7 months ago when 8.3 came out? Recall that our numbering has been historically somewhat arbitrary as well (7.4 should probably have been 8.0, for example). I guess I don't understand where Joe User was supposed to have gotten the message that 7.4 was on its last legs. If anything, the fact that it is on patchlevel 21 suggests otherwise. Us hackers and developers shudder at seeing a 7.4 database, but there are plenty of businesses who are still using it, and I think we owe it to them to give more advance warning that no more patchlevels are coming along than 3 months. Additionally, I don't know that it's possible to state up front how long a particular major release is going to be supported, as some have suggested. I think it's a great idea, but we tend to release "when we are ready", so any guess is only ever a guess. Further, as our product gets better and better, there will be an ever-increasing tendency to *not* upgrade to the latest and greatest, since the version they have already kicks ass, thank you very much[1]. [1] 8.3 rocks, by the way, thanks to all involved. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200809191545 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkjUAv4ACgkQvJuQZxSWSsiWCgCeJTIAgYLpP1fAdEQ59Bmik22p zGUAnRKciEyjpW9OqQey38JI24ei+bB8 =BRte -----END PGP SIGNATURE-----
Greg, > I agree with this 100%, my only issue is with the method and timing of > "making it clear". Until now, there has been zero indication from > the release notes, the website, or the community that 7.4 will be > soon unsupported. If we are going to announce that, we should be making > the announcement fair (e.g. not December 2008) and loud (e.g. -announce, > -general, main page of postgresql.org, press release). I agree, and would be happy to draft such an announcement, as soon as we agree on a date. -- --Josh Josh Berkus PostgreSQL San Francisco
Greg Sabino Mullane wrote: > I guess I don't understand where Joe User was supposed to have gotten > the message that 7.4 was on its last legs. If anything, the fact that > it is on patchlevel 21 suggests otherwise. Us hackers and developers > shudder at seeing a 7.4 database, but there are plenty of businesses > who are still using it, and I think we owe it to them to give more > advance warning that no more patchlevels are coming along than 3 > months. > The few postings I have noticed with users running 7.4 has been with a release several less than the newest. One of the first suggestions is always to install the newest update. Out of the users out there that still have 7.4 servers running, what percentage use the newest update? I am certain it's not 100% I doubt it would be much more that 50% I would think the old rule of don't fix what ain't broke would be fairly common among 7.4 users. The fact that it took 5 years to find a problem to be fixed would indicate that it isn't a show stopping issue that they need fixed. Supporting old versions is a great and noble thing but there comes a time when it is a waste of resources because the effort goes unused. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz
Shane Ambler <pgsql@Sheeky.Biz> writes:
> The few postings I have noticed with users running 7.4 has been with a
> release several less than the newest. ...
> Supporting old versions is a great and noble thing but there comes a
> time when it is a waste of resources because the effort goes unused.
Yeah, that's a really good point. An example is that Red Hat is still
shipping/supporting 7.4.x in RHEL 4, but it's been quite a long time
since I've been able to persuade them to push a 7.4.x update that didn't
involve a security issue. (They're currently shipping 7.4.19, and I'm
not even going to bother suggesting an update to .22.)
Probably everyone has got their own slightly different set of hot-button
considerations for whether it's worth updating to a new minor release,
but it's really unclear that there's going to be any uptake at all for
7.4.22 as constituted, because the bugs it fixes are so minor.
The suggestion I started this thread with amounted to not bothering with
pushing 7.4.x updates in update cycles where we'd made no "serious" bug
fixes in it; which is a very long way from desupport. Maybe an
appropriate compromise is to announce now that 7.4 is in maintenance
mode and will receive only really critical bug fixes (which are the only
ones that 7.4.x users are going to pay attention to anyway, so nothing
is lost); and that actual desupport will occur a year from now.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Tom Lane wrote: > The suggestion I started this thread with amounted to not bothering with > pushing 7.4.x updates in update cycles where we'd made no "serious" bug > fixes in it; which is a very long way from desupport. Maybe an > appropriate compromise is to announce now that 7.4 is in maintenance > mode and will receive only really critical bug fixes (which are the only > ones that 7.4.x users are going to pay attention to anyway, so nothing > is lost); and that actual desupport will occur a year from now. +1 Shall we set an exact date, such as October 1, 2009? - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200809201226 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkjVJDgACgkQvJuQZxSWSsjCuACgxGqmADfgGlHekGI+TXfQTAnr CroAnAuMs9sMcRvjBBDFlYV5+dY8wlra =c5fb -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > Tom Lane wrote: > >> The suggestion I started this thread with amounted to not bothering with >> pushing 7.4.x updates in update cycles where we'd made no "serious" bug >> fixes in it; which is a very long way from desupport. Maybe an >> appropriate compromise is to announce now that 7.4 is in maintenance >> mode and will receive only really critical bug fixes (which are the only >> ones that 7.4.x users are going to pay attention to anyway, so nothing >> is lost); and that actual desupport will occur a year from now. > > +1 > > Shall we set an exact date, such as October 1, 2009? Let's include 8.0 in that announcement so we aren't having this discussion again in a year. Joshua D. Drake
Joshua D. Drake wrote: > Greg Sabino Mullane wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: RIPEMD160 >> >> >> Tom Lane wrote: >> >>> The suggestion I started this thread with amounted to not bothering with >>> pushing 7.4.x updates in update cycles where we'd made no "serious" bug >>> fixes in it; which is a very long way from desupport. Maybe an >>> appropriate compromise is to announce now that 7.4 is in maintenance >>> mode and will receive only really critical bug fixes (which are the only >>> ones that 7.4.x users are going to pay attention to anyway, so nothing >>> is lost); and that actual desupport will occur a year from now. >> >> +1 >> >> Shall we set an exact date, such as October 1, 2009? > > Let's include 8.0 in that announcement so we aren't having this > discussion again in a year. Are we ready enough to actually put a *timeline* on the website? Meaning, can we already put in preliminary dates for *all* released versions? //Magnus
Magnus Hagander wrote: >>> Shall we set an exact date, such as October 1, 2009? >> Let's include 8.0 in that announcement so we aren't having this >> discussion again in a year. > > Are we ready enough to actually put a *timeline* on the website? > Meaning, can we already put in preliminary dates for *all* released > versions? I would think so. IMO: 3 years - Maintenance mode only 5 years - End of life Of course we need to define what maintenance mode only means. Joshua D. Drake
Joshua D. Drake wrote: > > > 3 years - Maintenance mode only > 5 years - End of life > > Of course we need to define what maintenance mode only means. > > We effectively put each release into maintenance mode on day 1, ISTM. cheers andrew
Andrew Dunstan wrote: > > > Joshua D. Drake wrote: >> >> >> 3 years - Maintenance mode only >> 5 years - End of life >> >> Of course we need to define what maintenance mode only means. >> >> > > We effectively put each release into maintenance mode on day 1, ISTM. > True enough. Joshua d. Drake > cheers > > andrew >
2008/9/20 Joshua D. Drake <jd@commandprompt.com>: > Andrew Dunstan wrote: >> >> >> Joshua D. Drake wrote: >>> >>> >>> 3 years - Maintenance mode only >>> 5 years - End of life >>> >>> Of course we need to define what maintenance mode only means. >>> >>> >> >> We effectively put each release into maintenance mode on day 1, ISTM. >> > > True enough. > Surely it should be x years from the release of the next major version or something Not x years from release. If we say End of Life is x years from release then don't get round to releasing for ages a version may reach end of life with nothing to replace it. (Which will happen if we ever exhaust the To Do list (bit pie in the sky but never mind)) Peter
Andrew Dunstan <andrew@dunslane.net> writes:
> Joshua D. Drake wrote:
>> Of course we need to define what maintenance mode only means.
> We effectively put each release into maintenance mode on day 1, ISTM.
Well, that would depend on your definition of "maintenance mode" ;-)
Your statement would be true if you define it as "no new features" but
that is nowhere near what I have in mind here. I'm thinking something
closer to "we'll only fix critical security and data-loss risks"; and
it would only apply to releases that are approaching the end of their
life cycle.
In particular, we need to define things in a way that explains/justifies
changing more stuff in 8.3 than in 7.4. "Maintenance mode starts on
day of release" is not only unhelpful but counterproductive for that
discussion.
regards, tom lane
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Magnus Hagander wrote:
>> Are we ready enough to actually put a *timeline* on the website?
> I would think so. IMO:
> 3 years - Maintenance mode only
> 5 years - End of life
I'm not really in favor of a one-size-fits-all approach to this.
Our various releases have had different levels of uptake and don't
necessarily all deserve the same support lifespan.
Case in point: we already obsoleted 8.0 and 8.1 for our Windows users.
How sensible is it to argue that they'll deserve a lifespan equivalent
to 8.2's?
The above numbers seem reasonable as a rough guideline, but I think the
actual decisions will need to be taken on a release-by-release basis.
regards, tom lane
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> Magnus Hagander wrote: >>> Are we ready enough to actually put a *timeline* on the website? > >> I would think so. IMO: >> 3 years - Maintenance mode only >> 5 years - End of life > > I'm not really in favor of a one-size-fits-all approach to this. > Our various releases have had different levels of uptake and don't > necessarily all deserve the same support lifespan. > > Case in point: we already obsoleted 8.0 and 8.1 for our Windows users. > How sensible is it to argue that they'll deserve a lifespan equivalent > to 8.2's? I believe those are different arguments though. The Windows product is still a relatively young and immature release. Our nix product is not. Besides there is always an exception to the rule :). I have no problem with, unless otherwise specified... > > The above numbers seem reasonable as a rough guideline, but I think the > actual decisions will need to be taken on a release-by-release basis. > Nod. Joshua D. Drake