This is the release dashboard: https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328255
*NOTE: *If you have set a Fix Version of 0.29.0 on a ticket that is not a blocker for 0.29.0/1.0 release, please unset the fix version. On Thu, May 26, 2016 at 3:44 PM, Vinod Kone <vinodk...@apache.org> wrote: > 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 >> >> >> > >> > >> > >
