On 01/20/2016 08:51 AM, Bruce Momjian wrote:
On Wed, Jan 20, 2016 at 07:53:25AM -0800, Joshua Drake wrote:
#2 This is a longer topic. I have been stewing in my head about
releases for years. I have even brought up the idea of an Ubuntu
style release cycle on list once or twice. The more I think about
it, the more I think this can help our community. We essentially
would have two types of releases:
STS:
* Supported for 1 release cycle plus 6 months (18-24 months)
* Inline upgrades supported
LTS:
* Supported for standard 5 years
* Is allowed to break binary format from STS but not previous LTS.
This allows two LTS versions per 5 year support cycle
I just don't buy the Ubuntu release model for our database. Ubuntu is
trying to balance hot features vs stability, while we are really focused
on stability, similar to Debian.
I understand but I think we are missing out on an opportunity here.
Notice that the shorter release cycle for STS will actually make some
things easier. Including:
* Increased test base (just like Fedora/Ubuntu)
* Increased early adopter testing (that is what early adopting is
really about for us anyway)
* Decreased concerns about upgrades and ability to extend upgrade status.
I am not in any way suggesting that this is a slam dunk but I do think
something along these lines can really bring forth a lot of
possibilities. Here is another example:
pg_audit was pulled from core, did it have to be? I can't say. I didn't
read the code. I was a proactive member stating we could pull it though
because it was an extension.
However, if it was an STS release it was going into we could be a little
more relaxed and say, "O.k. let's get this into the wild for some
general user testing".
There are a lot of people (think about the multixact problem) that will
run any software because it is new. Let's put the proper disclaimers on
there and let them run it.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
