whirr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <tom.e.wh...@gmail.com>
Subject Re: Contrib for new services
Date Wed, 01 Jun 2011 14:55:49 GMT
There's a balance between compatibility and introducing new features.
As a young project, my feeling is that it is OK for Whirr to break
compatibility between releases - until we reach version 1.0 (then it
won't be allowed except between major version numbers). The fact that
most (all?) of the Whirr service implementations live in the same
tree, and that there are not many of them, makes this reasonable for
users, since we make sure they get updated and tested. This is how
we've been operating so far. However, this doesn't scale well so it's
good to think about how we'd like to operate when there are more
services.

Andrei, what would the impact be of your proposal on releases? Do we
only ship services that compile (and pass tests) at the time of
release? Or are you suggesting a separate release of services?

Tom

On Mon, May 30, 2011 at 1:59 PM, Andrei Savu <savu.andrei@gmail.com> wrote:
> Tom, what do you think? Would it be useful to have some sort of
> Manifest file for each service we add so that we can have the freedom
> to evolve the core without being forced to update all the services?
>
> -- Andrei
>
> On Mon, May 30, 2011 at 7:36 PM, Adrian Cole <adrian@jclouds.org> wrote:
>> On Mon, May 30, 2011 at 9:28 AM, Andrei Savu <savu.andrei@gmail.com> wrote:
>>> On Mon, May 30, 2011 at 7:23 PM, Adrian Cole <adrian@jclouds.org> wrote:
>>>> I like the sandbox concept, as this is more about them being
>>>> unfinished then something that we wouldn't pull in.
>>>
>>> Yes and we should be able to change the core without having to update
>>> all the services to support the new features (e.g rolling restarts,
>>> reconfiguration).
>>>
>>> Should we add something like a supported list of Whirr capabilities
>>> for each service?
>> +1
>>
>

Mime
View raw message