Thanks for asking the questions Zameer. Wanted to give some clarification regarding the thought process for releasing 1.0.
The reason for cutting a 1.0, is because we want to signal that the Mesos project has reached a level of maturity to the wider community. Among other things we are confident at this point that the *foundations* we laid for the new APIs are mature and could be evolved in a backwards compatible way. We laid the foundations almost an year ago (at last MesosCon) and since then have been busy implementing the backend to drive the API. Even the newly released design doc for the operator API is built on the same foundations as the scheduler/executor APIs. While we have been tweaking the API backend for a while now the API definitions have mostly stayed the same. Part of the reason it took this long is because we really wanted to be sure the basic building blocks were solid. MesosCon is a great opportunity for us to drum up excitement about the new APIs and invite them to start using/testing it. Like any other OSS project, as people and organizations start using the new APIs in staging and production, we will make stability and implementation improvements. The long period for the RC will also help catching issues with API foundations themselves. We have had a bit of chicken and egg problem having people consume the new APIs because most don't want to use it in production unless it is declared production ready and we can't call it production ready until someone uses them in production. Having said all that stability and production readiness is paramount for the project. That is never going to change. In the case of the new APIs, we have developed C++ frameworks using the new APIs and having been running them as part of ASF CI for months now. Mesosphere, for example, also has an internal cluster where frameworks using these new APIs have been baking for a while and had done (and doing) rigorous tests (network partitions, scaling tests, functional tests). Community members from IBM have also been instrumental in testing the new APIs. We are hoping after 1.0 more people would be willing and excited to consume these new APIs and stress test in their environments. At the end of the day, while new APIs are an important part of Mesos 1.0 it's not the only reason for cutting a 1.0 release. Mesos has a slew of exciting features and a thriving eco system and we would love to have more people excited and get a taste of it. 1.0 is just a start... Hope that helps, On Wed, May 25, 2016 at 4:57 PM, Zameer Manji <zma...@apache.org> wrote: > 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 <vinodk...@apache.org> 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 < > > jeffschroe...@computer.org> 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 <vinodk...@apache.org> 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 > >> > > > > >
