> On March 18, 2016, 6:51 p.m., Vinod Kone wrote: > > Looks good to me. Couple of things before this can get committed. > > > > --> Have you sent an email to dev/user list about this backwards > > incompatible change? If not, you should. > > > > --> If users are depending on the return code (need to ask on the above > > email) we need to do a proper deprecation warning in 0.29.0 CHANGELOG > > (Deprecations section) and change the behavior in 0.30.0. > > > > --> If no one is depending on the return code, we might just do the change > > in 0.29.0. This should go into the 0.29.0 CHANGELOG though (API Changes > > section). > > zhou xing wrote: > Thanks for the review, we have sent a message to the community to see > wether anyone are using the return code. will update you the latest feedbacks > we collect, thx > > Kevin Klues wrote: > I Zhao, I'm curious if you got any feedback on this. Also, did you get a > chance to address Neil's comments about updating the documentation? I think > that would need to be included as part of this work, though I'd probably > submit it as a separate patch that "Depends On" this one. > > zhou xing wrote: > Kevin, we haven't got any response for this issue from the community yet. > So I'm thinking whether we can just merge this patch in release 0.29? if so, > I can update the change log and submit another patch, thanks
I think making this change in 0.29 is probably reasonable, provided we include the appropriate notices in the release notes / changelog / update doc. - Neil ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/44606/#review124249 ----------------------------------------------------------- On April 7, 2016, 8:56 a.m., zhou xing wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/44606/ > ----------------------------------------------------------- > > (Updated April 7, 2016, 8:56 a.m.) > > > Review request for mesos, Guangya Liu, Neil Conway, Qian Zhang, and Vinod > Kone. > > > Bugs: mesos-4580 > https://issues.apache.org/jira/browse/mesos-4580 > > > Repository: mesos > > > Description > ------- > > Modify the return code of the following endpoints to 202: > 1. /reserve > 2. /unreserve > 3. /create-volumes > 4. /destroy-volumes > > [#MESOS-4580] > > > Diffs > ----- > > CHANGELOG 4553465cc3dc17956f168469d405f7a453d6359e > docs/endpoints/master/create-volumes.md > 52ae3a8159bb7d26b63f5889ce3f122371afbdc4 > docs/endpoints/master/destroy-volumes.md > a0bb1e8d1ce42ab2b96518cd4d325bfc541ad4ff > docs/endpoints/master/reserve.md 1d481b56d380d45218001513330b225ca4a0a55c > docs/endpoints/master/unreserve.md b9282df659ebb6090ef49ef8fc0f01411cd53103 > docs/persistent-volume.md ab6ed8227259384261dd5f7c2e353753f20e5c19 > docs/reservation.md 75357206085848826b70c2d6f2be93d20e771604 > docs/upgrades.md 64c6a02dd54ddf06c557b38e08916dc10e484cdd > src/master/http.cpp f781fd0102c247b2e77a71f7be82b872b0831681 > src/tests/persistent_volume_endpoints_tests.cpp > 9b8ad34469c0c9a986aa60f3a52584a3a9eabb2b > src/tests/reservation_endpoints_tests.cpp > 2e0f6c1aba95d918b8c42219ee97f79f1070d56e > > Diff: https://reviews.apache.org/r/44606/diff/ > > > Testing > ------- > > > Thanks, > > zhou xing > >
