Oh, I see. Do we know how it's going to change? Ben discussed this with me 
earlier and I thought you guys had a specific plan (involving a new callback in 
the executor). If this is the case, we should add the API in even if the 
callback never gets called right now.

The reason I'm saying this is that even though there aren't that many 
frameworks on Mesos yet, API changes are quite confusing. For example, a lot of 
people who build Spark build it against the wrong version, or follow 
instructions that worked two weeks ago (to download Mesos from SVN) but don't 
work now. This is especially true because Mesos hasn't had a new version number 
in a while, but it will still be true once there are versions. I don't want to 
maintain separate branches of Spark for separate versions of Mesos, and 
certainly not for separate commits of Mesos. So if it's not much overhead, 
let's try to get an API we know will handle the features planned for the 
foreseeable future in this release, and design future changes in a way that 
doesn't require user action (e.g. as new functions that the user can call but 
not new callbacks that they must update their code with).

Matei

On Feb 20, 2012, at 12:31 PM, Vinod Kone wrote:

> Sorry for the delayed response. If by users, you mean framework writers,
> then the API might change for them, especially on the executor side.
> 
> -- Vinod
> 
> 
> 
> On Sat, Feb 18, 2012 at 8:40 PM, Matei Zaharia <[email protected]>wrote:
> 
>> Vinod, why not save slave restarting for 1.1? It's not going to change the
>> APIs the user sees, right?
>> 
>> Matei
>> 
>> On Feb 17, 2012, at 3:43 PM, Andy Konwinski wrote:
>> 
>>> Ok. Unless anybody has more thoughts I'll create a [VOTE] thread for
>> using
>>> 0.9 for the release.
>>> 
>>> From my phone.
>>> On Feb 17, 2012 1:24 PM, "Haoyuan Li" <[email protected]> wrote:
>>> 
>>>> No strong opinion either. But if I was an user, I probably would not
>>>> consider it seriously if I saw the version number is 0.0.1...
>>>> 
>>>> Best,
>>>> 
>>>> Haoyuan
>>>> 
>>>> On Fri, Feb 17, 2012 at 12:39 PM, Ali Ghodsi <[email protected]>
>> wrote:
>>>> 
>>>>> I have no strong opinion, but 0.0.1 sounds like a really early
>>>>> prototype. The project has been active for several years and it's used
>>>>> in production, so 0.5 or 0.1 would make sense.
>>>>> 
>>>>> --Ali
>>>>> 
>>>>> On Thu, Feb 16, 2012 at 7:00 PM, Matei Zaharia <
>> [email protected]>
>>>>> wrote:
>>>>>> Why don't we start with 0.5 or even 1.0, given that we already had
>>>>> numbered alpha releases and the project has been around for a while?
>>>>>> 
>>>>>> Matei
>>>>>> 
>>>>>> On Feb 16, 2012, at 6:40 PM, Andy Konwinski <[email protected]>
>>>> wrote:
>>>>>> 
>>>>>>> I chatted with Ben about this, and we propose that we use 0.0.1 for
>>>> the
>>>>>>> version number for our first apache release, and we adopt versioning
>>>>> rules
>>>>>>> like these http://apr.apache.org/versioning.html (i.e. the version
>>>>> scheme
>>>>>>> is major.minor.patch).
>>>>>>> 
>>>>>>> Does anybody have thoughts or objections?
>>>>>>> 
>>>>>>> I've added a new "version" in JIRA called "0.0.1" that (pending this
>>>>>>> discussion) we can start using to keep track of which Issues are
>>>>> intended
>>>>>>> to go into the first release (see
>>>>>>> 
>>>> https://issues.apache.org/jira/browse/MESOS/fixforversion/12319875whichis
>>>>>>> currently pretty boring because I've only assigned one issue to it,
>>>> as a
>>>>>>> test)
>>>>>>> 
>>>>>>> Note: we used version numbers before entering the incubator to
>>>> identify
>>>>> our
>>>>>>> github tagged alpha "releases", the most recent one being alpha 0.4
>>>> (see
>>>>>>> https://github.com/mesos/mesos/tags)
>>>>>>> 
>>>>>>> Andy
>>>>> 
>>>> 
>> 
>> 

Reply via email to