Josh Berkus wrote:
> after the final minor release date, there is no guarantee
INAL, but that *seems* like it might open the community or its members
to lawsuits based on an implied guarantee up to the final minor
release date.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Tom Lane wrote:
>> I'd suggest that we publish an official policy, with the following dates
>> for "EOL":
>
> But on the whole I think we should NOT have such a policy, at all.
[...]
> If someone wants a guaranteed EOL date, they ought to be contracting
> with a commercial support company and pay
Greg Stark wrote:
> On Mon, Jul 13, 2009 at 2:07 AM, Bruce Momjian wrote:
> > This might open the larger question of: ?What do we actually _promise_
> > users?
>
> The discussion had already covered that ground. If someone wants a
> promise they'll have to fork over money to one of the companies w
On Mon, Jul 13, 2009 at 2:07 AM, Bruce Momjian wrote:
> This might open the larger question of: Â What do we actually _promise_
> users?
The discussion had already covered that ground. If someone wants a
promise they'll have to fork over money to one of the companies which
sell such things.
That's
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > For what it's worth I find it hard to believe anyone's really
> > surprised by this. Nearly all other open source projects stop
> > supporting old branches as soon as
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> For what it's worth I find it hard to believe anyone's really
> surprised by this. Nearly all other open source projects stop
> supporting old branches as soon as there's a newer branch is released.
I'm not surprised at all. Our product holds
On Sun, Jul 12, 2009 at 11:53 PM, Josh Berkus wrote:
>
> Well, what I'm really concerned about is letting people know that we expect
> to *stop* providing update versions after 5 years.
That seems like a reasonable thing to say and you've just said it more
simply than any of your previous proposal
For an open source project, would such a statement really mean
anything more than "we'll provide support as long as some
community members feel like it, and we guess that's about 5 years"?
Well, what I'm really concerned about is letting people know that we
expect to *stop* providing update v
Josh Berkus wrote:
> I'd suggest that we publish an official policy, with the following dates
> for "EOL":
> 7.4 2009-08-01 ...
> 8.4 2014-08-01
What would such forward-looking statements even mean for a
community-driven project?
I assume for a commercial product, such a statement would mean
Josh Berkus wrote:
Hmmm, how about this?
"The current policy of the PostgreSQL community is to stop providing
minor versions (patches or updates) of PostgreSQL five years after a
version of PostgreSQL is released.
I think this is putting it the wrong way round. We should say that the
gen
Hmmm, how about this?
"The current policy of the PostgreSQL community is to stop providing
minor versions (patches or updates) of PostgreSQL five years after a
version of PostgreSQL is released. In general, users can expect to
continue to be able to get community updates for five years.
How
On Fri, 10 Jul 2009 19:51:31 -0400
Tom Lane wrote:
> Josh Berkus writes:
> > I'd suggest that we publish an official policy, with the following dates
> > for "EOL":
>
> I have no objection to setting an EOL date for 7.4 now, but I think it
> is premature to set EOL dates for later versions. I
On Jul 10, 2009, at 5:39 PM, Tom Lane wrote:
I don't mind the idea of saying "our intention is to support new
releases for about five years", or something equally squishy.
But a list of dates in black and white does not look reasonable,
especially not dates that are four or five years out for ve
Tom Lane wrote:
Andrew Dunstan writes:
I think we can avoid most of these problems by making a "best effort"
policy rather than a hard promise. But it can be moderately specific
about what we will make best efforts towards. I agree that anyone who
wants a hard promise should be getting co
Andrew Dunstan writes:
> I think we can avoid most of these problems by making a "best effort"
> policy rather than a hard promise. But it can be moderately specific
> about what we will make best efforts towards. I agree that anyone who
> wants a hard promise should be getting commercial supp
Tom Lane wrote:
But on the whole I think we should NOT have such a policy, at all.
If we'd enunciated such a thing in 2005, we'd still be on the hook to
support 8.0 on Windows; or else have had to go back on our word. The
truth of the matter is that the community will make reasonable efforts
t
On Jul 10, 2009, at 6:01 PM, Josh Berkus wrote:
All,
I'd suggest that we publish an official policy, with the following
dates for "EOL":
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
"After the above dates,
David E. Wheeler wrote:
> On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote:
>
> > All,
> >
> > I'd suggest that we publish an official policy, with the following
> > dates for "EOL":
> >
> > 7.4 2009-08-01
> > 8.0 2010-02-01
> > 8.1 2011-01-01
> > 8.2 2012-01-01
> > 8.3 2013-03-01
> > 8.
Josh Berkus writes:
> I'd suggest that we publish an official policy, with the following dates
> for "EOL":
> 7.4 2009-08-01
> 8.0 2010-02-01
> 8.1 2011-01-01
> 8.2 2012-01-01
> 8.3 2013-03-01
> 8.4 2014-08-01
I have no objection to setting an EOL date for 7.4 now, but I think it
is
On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote:
All,
I'd suggest that we publish an official policy, with the following
dates for "EOL":
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
"After the above dates, t
All,
I'd suggest that we publish an official policy, with the following dates
for "EOL":
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
"After the above dates, the PostgreSQL Project will not promise to
provide
Andrew Dunstan wrote:
<...>
> > branch | released | curr_version | curr_date | final_date
> > ++--++
> > 8.4| 2009-07-01 | 8.4.0| 2009-07-01 |
> > 8.3| 2008-02-04 | 8.3.7| 2009-03-16 |
> > 8.2| 2006-12-0
On Jul 7, 2009, at 12:59 PM, Alvaro Herrera wrote:
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have
formal
control over scheduled maintenance expirations…
The web team already has a table, and it is published
David E. Wheeler wrote:
> On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote:
>
>>> And it only goes back to 8.0
>>
>> Huh, true :-( This should be fixed.
>
> Yeah. Or we should have a table. I could create one in the wiki, I
> guess, but I would assume that the core team would want to have forma
David E. Wheeler wrote:
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
One thing I think we really should do is give prominent public notice
of any EOL for a branch. At least a couple of months, preferably. If
the lifetime were absolutely fixed it might not matter so much, but
as it isn'
On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote:
And it only goes back to 8.0
Huh, true :-( This should be fixed.
Yeah. Or we should have a table. I could create one in the wiki, I
guess, but I would assume that the core team would want to have formal
control over scheduled maintenanc
David E. Wheeler wrote:
> On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote:
>
>> We have an RSS:
>> http://www.postgresql.org/versions.rss
>
> Does anyone use it?
No idea.
> And it only goes back to 8.0
Huh, true :-( This should be fixed.
> and it served with the text/html content-type.
Not
On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote:
We have an RSS:
http://www.postgresql.org/versions.rss
Does anyone use it? And it only goes back to 8.0 and it served with
the text/html content-type.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
David E. Wheeler wrote:
> On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
>
>> One thing I think we really should do is give prominent public notice
>> of any EOL for a branch. At least a couple of months, preferably. If
>> the lifetime were absolutely fixed it might not matter so much, but as
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote:
One thing I think we really should do is give prominent public
notice of any EOL for a branch. At least a couple of months,
preferably. If the lifetime were absolutely fixed it might not
matter so much, but as it isn't I think we owe that to
David E. Wheeler wrote:
On Jul 7, 2009, at 8:06 AM, Tom Lane wrote:
I'd personally be perfectly happy with a community decision to desupport
7.4 now, or perhaps after the next set of update releases (which we're
probably overdue for, BTW). We cannot support an indefinitely large set
of back
On Jul 7, 2009, at 8:06 AM, Tom Lane wrote:
I'd personally be perfectly happy with a community decision to
desupport
7.4 now, or perhaps after the next set of update releases (which we're
probably overdue for, BTW). We cannot support an indefinitely large
set
of back branches, and a five-y
Dave Page writes:
> On Tue, Jul 7, 2009 at 8:28 AM, Heikki
> Linnakangas wrote:
>> Hmm, I thought we dropped support for 7.4 a while ago, and there's no
>> download link for it on www.postgresql.org anymore. But looking at the
>> CVS history, I see that others are still committing fixes to 7.4 bra
Heikki Linnakangas wrote:
David E. Wheeler wrote:
Howdy Hackers,
Is there a published maintenance policy somewhere? Something that says
for how long the project supports minor releases of PostgreSQL.
We don't have a published policy, but I believe an unofficial policy has
been to s
On Tue, Jul 7, 2009 at 8:28 AM, Heikki
Linnakangas wrote:
>> For
>> example, does 7.4 still get bug fixes and minor releases? If not, how
>> does one know when support for a major version has been dropped?
>
> Hmm, I thought we dropped support for 7.4 a while ago, and there's no
> download link fo
David E. Wheeler wrote:
> Howdy Hackers,
>
> Is there a published maintenance policy somewhere? Something that says
> for how long the project supports minor releases of PostgreSQL.
We don't have a published policy, but I believe an unofficial policy has
been to support minor releases for about
Howdy Hackers,
Is there a published maintenance policy somewhere? Something that says
for how long the project supports minor releases of PostgreSQL. For
example, does 7.4 still get bug fixes and minor releases? If not, how
does one know when support for a major version has been dropped?
37 matches
Mail list logo
