Re: Releasing in September

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Releasing in September
Date: 2016-01-22 15:03:41
Message-ID: 56A244CD.9080502@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/20/16 4:29 PM, Bruce Momjian wrote:
> On Wed, Jan 20, 2016 at 09:12:07AM -0800, Joshua Drake wrote:
>>> 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 can see LTS working for plugin change, but not server binary changes.

s/LTS/STS/?

In any case, I think JD is onto something here. As someone that focuses
more on user experience than "deep core" code, I already find yearly
releases to be quite inconvenient. It's hard to find the motivation to
make a minor improvement in something (especially knowing how hard it
will be to get the patch approved) knowing that it won't see the light
of day for a year, and realistically I won't be able to use it with any
clients that are in production for 2-3 years.

Given the high level of extensibility that we have, maybe it would be
good to logically segregate stuff into things that are deeply embedded
in the "core" code (ie: on-disk format) from things that are much easier
to change when necessary (like add-on functions or PLs). Things like new
JSON operators could be released much more rapidly that way.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Anastasia Lubennikova 2016-01-22 15:19:33 Re: WIP: Covering + unique indexes.
Previous Message Robert Haas 2016-01-22 15:00:31 Re: Releasing in September