You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Denitsa Burroughs <de...@gmail.com> on 2019/10/02 19:10:11 UTC
Re: Proposed deprecations / removals (was: Re: Getting started on
CouchDB 3.0, and an introduction)
Hi Joan, Adam, et al,
Ilya and I got together to review the deprecations list to a) determine if
there were any additional breaking changes required for 3.0 and b) ensure
we had a comprehensive list for documentation and release notes purposes.
We used this email thread and the tickets Adam created as a starting point.
Ilya identified a few other items that were missing from the lists. We've
summarized the changes in https://github.com/apache/couchdb/issues/2218
This ticket is specific to 3.0. Hopefully it would simplify the release
notes process. Please take a look - we are missing some of the
reference/decision links and some of the deprecations are not complete or
documented yet. (I will work with Ilya to update the table as we go since I
don't have edit permissions yet).
Proposed 1.x deprecations <https://github.com/apache/couchdb/issues/1534>
was also mentioned and is currently in the 3.0 tasks column. Should we
close this ticket? It appears quite old. Is there any information that
needs to be extracted and is required for 3.0?
Thanks,
Deni
On Mon, Sep 16, 2019 at 4:19 PM Adam Kocoloski <ko...@apache.org> wrote:
> I added https://github.com/apache/couchdb/issues/2191 to the 3.0 release
> tasks but I don’t know exactly what the desired end state looks like there.
>
> Adam
>
> > On Sep 14, 2019, at 3:11 PM, Joan Touzet <wo...@apache.org> wrote:
> >
> > Hi Deni, I think you mean Joan, not Jan. :D
> >
> > As I mentioned there isn't an issue yet, so we need to create one. I'm
> away from my credentials until Tuesday and can address this then, if no one
> gets to it first.
> >
> > -Joan
> >
> > On 2019-09-11 2:43 p.m., Denitsa Burroughs wrote:
> >> Hi Jan -
> >> Do you happen to have the ticket/link for this?
> >>> I remembered one last deprecation we wanted in 3.0: security
> tightening,
> >>> which included the deprecation of admin party.
> >>>
> >> Thanks!
> >> Deni
> >> On Mon, Sep 9, 2019 at 2:14 PM Joan Touzet <wo...@apache.org> wrote:
> >>> I remembered one last deprecation we wanted in 3.0: security
> tightening,
> >>> which included the deprecation of admin party.
> >>>
> >>> Jan can you find the ticket on this? I don't think it's the full #1504.
> >>> Just new defaults, and we'll need to think thru what happens when
> >>> starting up a node that has no [admins]. Do we create one and log its
> >>> password to the logfile? What if logging is disabled / goes nowhere? Or
> >>> do we simply refuse to start until an admin is created? What about
> >>> crypting and salting the password ahead of time - do we introduce a
> >>> small cli tool to generate passwords like apache/httpd does? Many
> >>> questions.
> >>>
> >>> -Joan
> >>>
> >>>
> >>> On 2019-09-04 5:37 p.m., Joan Touzet wrote:
> >>>> Hey Adam,
> >>>>
> >>>>> When it comes to deprecating and/or removing functionality, I feel
> like
> >>> I don’t know exactly where we stand today. We have occasionally
> described
> >>> some of the CouchApp functionality as already being deprecated, but I’m
> >>> having trouble finding any official record of that in our
> documentation.
> >>>> Thanks for re-opening the deprecation discussion. I've reviewed [1]
> and
> >>>> provide the following summary tables (Markdown format).
> >>>>
> >>>> **NOTE**: This is /not/ the vote for deprecation, nor a formal
> >>>> announcement of such. This is a starting point for discussion. A vote
> >>>> still needs to happen for this to move forward. Anything already
> >>>> deprecated in 2.0 can be removed in 3.0 without a formal vote, but
> it'd
> >>>> be nice if it got mentioned on the dev@ list before the PR lands on
> >>>> master, please.
> >>>>
> >>>> As I'm going to be travelling for most of the rest of September, I'd
> >>>> prefer if someone else (like Adam or Deni) can help drive this
> >>> discussion.
> >>>>
> >>>> Once there is consensus from the community on these lists, we should
> >>>> close #1534 and split it into 3 new tickets based on the tables below
> >>>> (excepting the features already removed in 2.x).
> >>>>
> >>>>> I guess let’s start with: does anyone believe we are in a position to
> >>> be eliminating previously-deprecated functionality in 3.0?
> >>>>
> >>>> Yes, for the items in the 2nd table below, absolutely.
> >>>>
> >>>> -Joan "turning the tables" Touzet
> >>>>
> >>>>
> >>>> --------
> >>>>
> >>>>
> >>>> # Recently removed features in 2.x
> >>>>
> >>>> **Feature/Endpoint** | **Links**
> >>>> ------------------------------------|------------
> >>>> update_notifications | [10]
> >>>> ini-file based query servers | [11]
> >>>> ini-file based HTTP global handlers | [11]
> >>>> OS daemons | [11],[12]
> >>>> vhost redirects/global handlers | [11],[12]
> >>>> couch_httpd_proxy | [11],[12]
> >>>>
> >>>> *NOTE*: Some of these still have lingering bits in the documentation
> >>>> that need a final cleanup pass before 3.0 should be released.
> >>>>
> >>>> --------
> >>>>
> >>>> # Already deprecated items, to be removed in 3.0
> >>>>
> >>>> **Feature/Endpoint** | **Links**
> >>>> ------------------------------------|------------
> >>>> some duplicate dbinfo size fields | [2],[3]
> >>>> delayed_commits | [4]
> >>>> port 5986 | [5],[6]
> >>>> `/{db}/_external/*` | [7],[8]
> >>>> view-based changes (code remnants) | [17],[18],[19],[20]
> >>>>
> >>>> --------
> >>>>
> >>>> # Proposed deprecations for 3.0, not rebuilt/removed in 4.0
> >>>>
> >>>> **Feature/Endpoint** | **Replaced by** | **Links**
> >>>> --------------------------|----------------------|-----------
> >>>> `/{db}/{ddoc}/_show/*` | App server/rev proxy | †
> >>>> `/{db}/{ddoc}/_list/*` | App server/rev proxy | †
> >>>> virtual hosts [24] | haproxy, multitenant | [25]
> >>>> `/{db}/{ddoc}/_rewrite/*` | App server/rev proxy | [26]
> >>>>
> >>>> †: getRow() makes embedding a new, efficient JS engine impossible
> since
> >>>> getRow() does not give up thread execution control; an entirely new
> >>>> approach would need to be constructed, breaking backward compatibility
> >>>> at the very least. (There are additional challenges.)
> >>>>
> >>>> --------
> >>>>
> >>>> # Likely will remain unchanged through 4.0
> >>>>
> >>>> **Feature/Endpoint** | **Improved by**
> >>>> ---------------------------------|----------------------
> >>>> VDU (validatefun()) [13] | [14],[15]
> >>>> update handlers (updatefun) [16] | [14],[15]
> >>>> JS engine [21] | [22],[23]
> >>>> system DB special handling | [27]
> >>>>
> >>>> *NOTE*: The last table may grow as limitations imposed by FDB are
> better
> >>>> understood.
> >>>>
> >>>> --------
> >>>>
> >>>> # References
> >>>>
> >>>> [1]: https://github.com/apache/couchdb/issues/1534
> >>>> [2]:
> >>>>
> >>>
> https://docs.couchdb.org/en/stable/api/database/common.html?highlight=disk-size#get--db
> >>>> [3]: https://github.com/apache/couchdb/pull/2163
> >>>> [4]:
> >>>>
> >>>
> https://github.com/apache/couchdb/blob/103a0624f309ea0d796176a55eb5faea68f26047/test/javascript/tests/delayed_commits.js#L16
> >>>> [5]: https://github.com/apache/couchdb/issues/1523
> >>>> [6]: https://github.com/apache/couchdb/pull/2092
> >>>> [7]: https://github.com/apache/couchdb/pull/1330
> >>>> [8]: https://docs.couchdb.org/en/stable/whatsnew/2.2.html
> >>>> [10]: https://github.com/apache/couchdb/pull/1476
> >>>> [11]: https://docs.couchdb.org/en/stable/whatsnew/2.3.html
> >>>> [12]: https://github.com/apache/couchdb/pull/1602
> >>>> [13]: https://docs.couchdb.org/en/stable/ddocs/ddocs.html#vdufun
> >>>> [14]: https://github.com/apache/couchdb/issues/1554
> >>>> [15]: https://github.com/apache/couchdb/pull/1898
> >>>> [16]:
> >>> https://docs.couchdb.org/en/stable/ddocs/ddocs.html#update-functions
> >>>> [17]: https://github.com/apache/couchdb/issues/592
> >>>> [18]: https://github.com/apache/couchdb/issues/831
> >>>> [19]:
> >>>>
> >>>
> https://lists.apache.org/thread.html/516793df0c1913c045441d0ff78339f307e2aff517d9223da44edd9e@%3Cdev.couchdb.apache.org%3E
> >>>> [20]:
> >>>>
> >>>
> http://docs.couchdb.org/en/stable/api/database/changes.html?highlight=selector#selector
> >>>> [21]: https://github.com/apache/couchdb/issues/1513
> >>>> [22]: https://github.com/apache/couchdb/issues/1875
> >>>> [23]: https://github.com/apache/couchdb/issues/1884
> >>>> [24]:
> https://docs.couchdb.org/en/stable/config/http.html#virtual-hosts
> >>>> [25]: https://github.com/apache/couchdb/issues/1539
> >>>> [26]:
> >>>>
> >>>
> https://docs.couchdb.org/en/stable/api/ddoc/rewrites.html#api-ddoc-rewrite
> >>>> [27]: https://github.com/apache/couchdb/issues/1534
> >>>>
> >>>
>
>
Re: Proposed deprecations / removals (was: Re: Getting started on
CouchDB 3.0, and an introduction)
Posted by Joan Touzet <wo...@apache.org>.
On 2019-10-02 15:10, Denitsa Burroughs wrote:
> Hi Joan, Adam, et al,
>
> Ilya and I got together to review the deprecations list to a) determine if
> there were any additional breaking changes required for 3.0 and b) ensure
> we had a comprehensive list for documentation and release notes purposes.
> We used this email thread and the tickets Adam created as a starting point.
> Ilya identified a few other items that were missing from the lists. We've
> summarized the changes in https://github.com/apache/couchdb/issues/2218
Added to 3.0 in the project.
> This ticket is specific to 3.0. Hopefully it would simplify the release
> notes process. Please take a look - we are missing some of the
> reference/decision links and some of the deprecations are not complete or
> documented yet. (I will work with Ilya to update the table as we go since I
> don't have edit permissions yet).
>
> Proposed 1.x deprecations <https://github.com/apache/couchdb/issues/1534>
> was also mentioned and is currently in the 3.0 tasks column. Should we
> close this ticket? It appears quite old. Is there any information that
> needs to be extracted and is required for 3.0?
Closed out. This mailing list discussion is definitive; that ticket
lived long past its useful lifetime.
> Thanks,
>
> Deni
>
>
>
> On Mon, Sep 16, 2019 at 4:19 PM Adam Kocoloski <ko...@apache.org> wrote:
>
>> I added https://github.com/apache/couchdb/issues/2191 to the 3.0 release
>> tasks but I don’t know exactly what the desired end state looks like there.
>>
>> Adam
>>
>>> On Sep 14, 2019, at 3:11 PM, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> Hi Deni, I think you mean Joan, not Jan. :D
>>>
>>> As I mentioned there isn't an issue yet, so we need to create one. I'm
>> away from my credentials until Tuesday and can address this then, if no one
>> gets to it first.
>>>
>>> -Joan
>>>
>>> On 2019-09-11 2:43 p.m., Denitsa Burroughs wrote:
>>>> Hi Jan -
>>>> Do you happen to have the ticket/link for this?
>>>>> I remembered one last deprecation we wanted in 3.0: security
>> tightening,
>>>>> which included the deprecation of admin party.
>>>>>
>>>> Thanks!
>>>> Deni
>>>> On Mon, Sep 9, 2019 at 2:14 PM Joan Touzet <wo...@apache.org> wrote:
>>>>> I remembered one last deprecation we wanted in 3.0: security
>> tightening,
>>>>> which included the deprecation of admin party.
>>>>>
>>>>> Jan can you find the ticket on this? I don't think it's the full #1504.
>>>>> Just new defaults, and we'll need to think thru what happens when
>>>>> starting up a node that has no [admins]. Do we create one and log its
>>>>> password to the logfile? What if logging is disabled / goes nowhere? Or
>>>>> do we simply refuse to start until an admin is created? What about
>>>>> crypting and salting the password ahead of time - do we introduce a
>>>>> small cli tool to generate passwords like apache/httpd does? Many
>>>>> questions.
>>>>>
>>>>> -Joan
>>>>>
>>>>>
>>>>> On 2019-09-04 5:37 p.m., Joan Touzet wrote:
>>>>>> Hey Adam,
>>>>>>
>>>>>>> When it comes to deprecating and/or removing functionality, I feel
>> like
>>>>> I don’t know exactly where we stand today. We have occasionally
>> described
>>>>> some of the CouchApp functionality as already being deprecated, but I’m
>>>>> having trouble finding any official record of that in our
>> documentation.
>>>>>> Thanks for re-opening the deprecation discussion. I've reviewed [1]
>> and
>>>>>> provide the following summary tables (Markdown format).
>>>>>>
>>>>>> **NOTE**: This is /not/ the vote for deprecation, nor a formal
>>>>>> announcement of such. This is a starting point for discussion. A vote
>>>>>> still needs to happen for this to move forward. Anything already
>>>>>> deprecated in 2.0 can be removed in 3.0 without a formal vote, but
>> it'd
>>>>>> be nice if it got mentioned on the dev@ list before the PR lands on
>>>>>> master, please.
>>>>>>
>>>>>> As I'm going to be travelling for most of the rest of September, I'd
>>>>>> prefer if someone else (like Adam or Deni) can help drive this
>>>>> discussion.
>>>>>>
>>>>>> Once there is consensus from the community on these lists, we should
>>>>>> close #1534 and split it into 3 new tickets based on the tables below
>>>>>> (excepting the features already removed in 2.x).
>>>>>>
>>>>>>> I guess let’s start with: does anyone believe we are in a position to
>>>>> be eliminating previously-deprecated functionality in 3.0?
>>>>>>
>>>>>> Yes, for the items in the 2nd table below, absolutely.
>>>>>>
>>>>>> -Joan "turning the tables" Touzet
>>>>>>
>>>>>>
>>>>>> --------
>>>>>>
>>>>>>
>>>>>> # Recently removed features in 2.x
>>>>>>
>>>>>> **Feature/Endpoint** | **Links**
>>>>>> ------------------------------------|------------
>>>>>> update_notifications | [10]
>>>>>> ini-file based query servers | [11]
>>>>>> ini-file based HTTP global handlers | [11]
>>>>>> OS daemons | [11],[12]
>>>>>> vhost redirects/global handlers | [11],[12]
>>>>>> couch_httpd_proxy | [11],[12]
>>>>>>
>>>>>> *NOTE*: Some of these still have lingering bits in the documentation
>>>>>> that need a final cleanup pass before 3.0 should be released.
>>>>>>
>>>>>> --------
>>>>>>
>>>>>> # Already deprecated items, to be removed in 3.0
>>>>>>
>>>>>> **Feature/Endpoint** | **Links**
>>>>>> ------------------------------------|------------
>>>>>> some duplicate dbinfo size fields | [2],[3]
>>>>>> delayed_commits | [4]
>>>>>> port 5986 | [5],[6]
>>>>>> `/{db}/_external/*` | [7],[8]
>>>>>> view-based changes (code remnants) | [17],[18],[19],[20]
>>>>>>
>>>>>> --------
>>>>>>
>>>>>> # Proposed deprecations for 3.0, not rebuilt/removed in 4.0
>>>>>>
>>>>>> **Feature/Endpoint** | **Replaced by** | **Links**
>>>>>> --------------------------|----------------------|-----------
>>>>>> `/{db}/{ddoc}/_show/*` | App server/rev proxy | †
>>>>>> `/{db}/{ddoc}/_list/*` | App server/rev proxy | †
>>>>>> virtual hosts [24] | haproxy, multitenant | [25]
>>>>>> `/{db}/{ddoc}/_rewrite/*` | App server/rev proxy | [26]
>>>>>>
>>>>>> †: getRow() makes embedding a new, efficient JS engine impossible
>> since
>>>>>> getRow() does not give up thread execution control; an entirely new
>>>>>> approach would need to be constructed, breaking backward compatibility
>>>>>> at the very least. (There are additional challenges.)
>>>>>>
>>>>>> --------
>>>>>>
>>>>>> # Likely will remain unchanged through 4.0
>>>>>>
>>>>>> **Feature/Endpoint** | **Improved by**
>>>>>> ---------------------------------|----------------------
>>>>>> VDU (validatefun()) [13] | [14],[15]
>>>>>> update handlers (updatefun) [16] | [14],[15]
>>>>>> JS engine [21] | [22],[23]
>>>>>> system DB special handling | [27]
>>>>>>
>>>>>> *NOTE*: The last table may grow as limitations imposed by FDB are
>> better
>>>>>> understood.
>>>>>>
>>>>>> --------
>>>>>>
>>>>>> # References
>>>>>>
>>>>>> [1]: https://github.com/apache/couchdb/issues/1534
>>>>>> [2]:
>>>>>>
>>>>>
>> https://docs.couchdb.org/en/stable/api/database/common.html?highlight=disk-size#get--db
>>>>>> [3]: https://github.com/apache/couchdb/pull/2163
>>>>>> [4]:
>>>>>>
>>>>>
>> https://github.com/apache/couchdb/blob/103a0624f309ea0d796176a55eb5faea68f26047/test/javascript/tests/delayed_commits.js#L16
>>>>>> [5]: https://github.com/apache/couchdb/issues/1523
>>>>>> [6]: https://github.com/apache/couchdb/pull/2092
>>>>>> [7]: https://github.com/apache/couchdb/pull/1330
>>>>>> [8]: https://docs.couchdb.org/en/stable/whatsnew/2.2.html
>>>>>> [10]: https://github.com/apache/couchdb/pull/1476
>>>>>> [11]: https://docs.couchdb.org/en/stable/whatsnew/2.3.html
>>>>>> [12]: https://github.com/apache/couchdb/pull/1602
>>>>>> [13]: https://docs.couchdb.org/en/stable/ddocs/ddocs.html#vdufun
>>>>>> [14]: https://github.com/apache/couchdb/issues/1554
>>>>>> [15]: https://github.com/apache/couchdb/pull/1898
>>>>>> [16]:
>>>>> https://docs.couchdb.org/en/stable/ddocs/ddocs.html#update-functions
>>>>>> [17]: https://github.com/apache/couchdb/issues/592
>>>>>> [18]: https://github.com/apache/couchdb/issues/831
>>>>>> [19]:
>>>>>>
>>>>>
>> https://lists.apache.org/thread.html/516793df0c1913c045441d0ff78339f307e2aff517d9223da44edd9e@%3Cdev.couchdb.apache.org%3E
>>>>>> [20]:
>>>>>>
>>>>>
>> http://docs.couchdb.org/en/stable/api/database/changes.html?highlight=selector#selector
>>>>>> [21]: https://github.com/apache/couchdb/issues/1513
>>>>>> [22]: https://github.com/apache/couchdb/issues/1875
>>>>>> [23]: https://github.com/apache/couchdb/issues/1884
>>>>>> [24]:
>> https://docs.couchdb.org/en/stable/config/http.html#virtual-hosts
>>>>>> [25]: https://github.com/apache/couchdb/issues/1539
>>>>>> [26]:
>>>>>>
>>>>>
>> https://docs.couchdb.org/en/stable/api/ddoc/rewrites.html#api-ddoc-rewrite
>>>>>> [27]: https://github.com/apache/couchdb/issues/1534
>>>>>>
>>>>>
>>
>>
>