Re: Add PostgreSQL 11 to feature matrix page?

>> On Jun 6, 2018, at 10:35 AM, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>>
>>>
>>> On Jun 6, 2018, at 9:09 AM, Magnus Hagander <magnus(at)hagander(dot)net <mailto:magnus(at)hagander(dot)net>> wrote:
>>>
>>>
>>>
>>> On Tue, Jun 5, 2018 at 1:59 AM, Jonathan S. Katz <jkatz(at)postgresql(dot)org <mailto:jkatz(at)postgresql(dot)org>> wrote:
>>>
>>>> On Jun 4, 2018, at 7:08 PM, Jonathan S. Katz <jkatz(at)postgresql(dot)org <mailto:jkatz(at)postgresql(dot)org>> wrote:
>>>>
>>>>>
>>>>> On May 24, 2018, at 10:09 PM, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp <mailto:ishii(at)sraoss(dot)co(dot)jp>> wrote:
>>>>>
>>>>> [Moved to pgsql-www]
>>>>
>>>> Sorry for the slow reply!
>>>>
>>>>>>> Adding PostgreSQL 11 to the page will give users at-a-glance-dfference
>>>>>>> between 11 and previous releases, which could bring clearner image of
>>>>>>> 11 to the users.
>>>>>>
>>>>>> I do like this idea, but there are a few things to consider:
>>>>>>
>>>>>> 1. Traditionally, we’ve waited until closer to release (I believe RCs) before
>>>>>> putting them up, due to the fact features can change. It is simple to remove
>>>>>> features from the feature matrix, but I think it’s part of the final packaging to
>>>>>> include the full list of features.
>>>>>
>>>>> But by definition, all features in beta (at least major ones) are
>>>>> freezed and should not be changed unless there's a serious
>>>>> technical/none technical issue. So the features in the matrix would
>>>>> not be changed we expect. Also one of the purposes of beta is
>>>>> encouraging users to test out the beta. Adding to the page will give
>>>>> more chances to potential beta testers, I think.
>>>>
>>>> I don’t disagree. I need to make a test to see if this is possible with
>>>> the current pgweb configuration.
>>>>
>>>> I will make a test on my local copy of pgweb to see how easy it is to add 11
>>>> to the list. I will report back if it is easy or not. If the former, I’ll make the suggestion
>>>> of adding it to the site and see if there are any objections.
>>>
>>> So to get this to work we need to follow the standard process of adding in
>>> a new version to the feature matrix:
>>>
>>> 1. Write a migration to support “v11” in the Feature model
>>> 2. Add in the new features
>>>
>>> The one thing currently is that unless something in the code is changed, it
>>> displays the full version number (e.g. “11”) without any indication of it being
>>> in beta. Experimenting with the code, I don’t think it would be difficult to add
>>> that in, but it is non trivial and I may have to change some of the sorting code
>>> we are currently using.
>>>
>>> tl;dr
>>>
>>> If we’re ok with displaying “11” early without any indication of beta, this is trivial
>>> and we just need to create the migration. If not, then it’s a bit of work, but it
>>> may be worthwhile.
>>>
>>> Thoughts?
>>>
>>>
>>> I think it's perfectly fine to show it as 11.
>>
>> See attached for review. This follows the standard format we have used for
>> adding new versions to the feature matrix.
>
> This patch has been applied.
>
> I’ve added a few of the PostgreSQL 11 features into the matrix just to get a basic
> list going:
>
> https://www.postgresql.org/about/featurematrix/ <https://www.postgresql.org/about/featurematrix/>
>
> Skimming through it, we may be due for some reorganization and some new
> categories, e.g. “Partitioning,” “Indexing” etc.
>
> I can think of some others after looking at it more thoroughly.

This is very helpful. Thanks!

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp