I might be in the minority here, but I think cutting an RC for 1.0 right now is very aggressive. Does there exist even a single framework that uses the Scheduler HTTP API or the Executor HTTP API? Does anyone even use these APIs in production? Is there a single entity that uses the Operator API to manage agents?
I think cutting an RC right now is 100% premature until the community can provide clear answers to these questions. I think Mesos project has been historically successful because its features were developed in a slow methodical manner and then battle tested by at least a user before the feature was declared 'stable' and ready for use for everyone. I think not following those steps here for the HTTP APIs is a huge error. On Wed, May 25, 2016 at 12:51 PM, Vinod Kone <[email protected]> wrote: > Post 1.0. Jie might be able to shed more light regarding the plans for > Docker Containerizer. > > On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder < > [email protected]> wrote: > >> Does this mean the work to deprecate the docker containerizer will be >> post-1.0, or have those plans changed? >> >> >> On Wednesday, May 25, 2016, Vinod Kone <[email protected]> wrote: >> >>> Hi folks, >>> >>> As discussed in the previous community sync, we plan to cut a release >>> candidate for our next release (1.0) early next week. >>> >>> 1.0 is mainly centered around new APIs for Mesos. Please take a look at >>> MESOS-338 <https://issues.apache.org/jira/browse/MESOS-338> for >>> blocking issues. We got some great design and testing feedback for the v1 >>> scheduler and executor APIs. Please do the same for the in-progress v1 >>> operator API >>> <https://docs.google.com/document/d/1XfgF4jDXZDVIEWQPx6Y4glgeTTswAAxw6j8dPDAtoeI/edit?pref=2&pli=1#> >>> . >>> >>> Since this is a 1.0, we would like to do the release a little >>> differently. >>> >>> First, the voting period for vetting the release candidate would be a >>> few weeks (2-3 weeks) instead of the typical 3 days. >>> >>> Second, we are wiling to make major changes (scalability fixes, API >>> fixes) if there are any issues reported by the community. >>> >>> We are doing these because we really want the community to thoroughly >>> test the 1.0 release and give feedback. >>> >>> Thanks, >>> >> >> >> -- >> Text by Jeff, typos by iPhone >> > >
