From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
Cc: | pgsql-www(at)postgresql(dot)org |
Subject: | Re: Add PostgreSQL 11 to feature matrix page? |
Date: | 2018-06-04 23:59:33 |
Message-ID: | 8699A330-96F5-4744-B681-4452914F1632@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-www |
> On Jun 4, 2018, at 7:08 PM, Jonathan S. Katz <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?
Jonathan
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-06-05 00:16:31 | Re: [PATCH v16] GSSAPI encryption support |
Previous Message | David G. Johnston | 2018-06-04 23:51:26 | Re: Remove mention in docs that foreign keys on partitioned tables are not supported |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-06-05 00:18:24 | Re: Code of Conduct plan |
Previous Message | Tom Lane | 2018-06-04 23:23:56 | Re: Code of Conduct plan |