I think marking it as deprecated would be the way to go. Then clean it up in the next major (!) release (e.g. 2.0).
Till On Wed, Jul 28, 2010 at 1:55 PM, Volker Mische <[email protected]> wrote: > I think deprecating parts of the API after 1.0 is alright, as long if it's > still there till the next stable major release. > > We extend the API, and I don't see a difference between extending it with a > new value for an existing key and extending it with a new key. Except that > the latter is cleaner in this case IMHO. > > Though I could also live with "stale=update_after". > > Cheers, > Volker > > On 07/28/2010 01:40 PM, Filipe David Manana wrote: >> >> Do we have some JIRA allergy? >> >> I don't mind a new parameter, whatever its name might be. But it >> introduces a bigger change in the API, and abandoning "stale" in >> favour of this new parameter wouldn't be reasonable before at least >> one major release (2.0, 3.0 whatever, but definitely not 1.x). >> >> I would like to have this (independently of the naming we use) for 1.1. >> Raise your hands if you're against or in favour of >> "stale=update_after" (seems meaningful to me). >> >> >> >> On Wed, Jul 28, 2010 at 7:21 AM, Sebastian Cohnen >> <[email protected]> wrote: >>> >>> this is exactly what I tried to say with my comment :) add a new >>> parameter and keep stale=ok (with its current behavior around for backward >>> compatibility) >>> >>> On 27.07.2010, at 23:47, Volker Mische wrote: >>> >>>> I prefer Roberts suggestion. Adding a new parameter that will replace >>>> stale in the long run, that has understandable values. stale=ok could be >>>> kept and deprecated and finally replaced in a 1.1/2.0. >>>> >>>> update=now|no|after sounds good (though now/no has a high chance of a >>>> typo). >>>> >>>> Cheers, >>>> Volker >>>> >>>> On 07/27/2010 11:40 PM, Robert Newson wrote: >>>>> >>>>> this could run forever so stale=update_after is as good as any >>>>> suggestion so far. I say get it on trunk, if anyone feels strongly, >>>>> there's time before it's in a release. >>>>> >>>>> ?update=now (default)|no|later/next/after might be better but breaks >>>>> back compatibility. >>>>> >>>>> B. >>>>> >>>>> On Tue, Jul 27, 2010 at 10:36 PM, Klaus Trainer<[email protected]> >>>>> wrote: >>>>>> >>>>>> +1 >>>>>> This one sounds good. It clearly makes obvious the update semantics. >>>>>> >>>>>> >>>>>> On Tue, 2010-07-27 at 17:27 -0400, Filipe Manana (JIRA) wrote: >>>>>>> >>>>>>> [ >>>>>>> https://issues.apache.org/jira/browse/COUCHDB-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892934#action_12892934 >>>>>>> ] >>>>>>> >>>>>>> Filipe Manana commented on COUCHDB-837: >>>>>>> --------------------------------------- >>>>>>> >>>>>>> So, having a: >>>>>>> >>>>>>> "stale=update_after" >>>>>>> >>>>>>> Anyone against? >>>>>>> >>>>>>>> Adding stale=partial >>>>>>>> -------------------- >>>>>>>> >>>>>>>> Key: COUCHDB-837 >>>>>>>> URL: >>>>>>>> https://issues.apache.org/jira/browse/COUCHDB-837 >>>>>>>> Project: CouchDB >>>>>>>> Issue Type: Improvement >>>>>>>> Environment: all released and unreleased versions >>>>>>>> Reporter: Filipe Manana >>>>>>>> Assignee: Filipe Manana >>>>>>>> Attachments: stale_partial.patch >>>>>>>> >>>>>>>> >>>>>>>> Inspired by Matthias' latest post, at >>>>>>>> http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html, >>>>>>>> section "Views are updated on read access", I added a new value to the >>>>>>>> "stale" option named "partial" (possibly we need to find a better >>>>>>>> name). >>>>>>>> It behaves exactly like "stale=ok" but after replying to the client, >>>>>>>> it triggers a view update in the background. >>>>>>>> Patch attached. >>>>>>>> If no one disagrees this isn't a good feature, or suggest a better >>>>>>>> parameter value name, I'll commit. >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >>> >> >> >> > >
