> 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
> 
>

Reply via email to