whirr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Savu <savu.and...@gmail.com>
Subject Re: Contrib for new services
Date Wed, 01 Jun 2011 18:14:21 GMT
I understand your concerns and also I see that's not trivial to test even a
single version of a service released together with the whirr core.

I guess it's reasonable to postpone this decision as long as we can still
maintain all the services.
 On Jun 1, 2011 8:04 PM, "Adrian Cole" <adrian@jclouds.org> wrote:
> I like the *idea* of having separate releases for services and core,
> but while sands are shifting it might be error-prone maintenance and
> build dependencies.
>
> How about if we work to increase the frequency of releases, including
> a contrib build, until the core apis solidify? I think there's still
> more to gain from minds on coding at this point vs managing dozens of
> individual release projects. Moreover, there will be less "my
> classpath doesn't work" issues from onset if versions are consistent,
> especially knowing the classpath will near certainly be incompatible
> between core and services for another release or so.
>
> I don't mean to discourage, rather to highlight that this is a lot of
> effort and will likely increase the errors users will encounter for
> the perception of more scalable deployment. I'm of the opinion that
> this will be scalable once core is a bit less shakey.
>
> my 2p.
> -a
>
> On Wed, Jun 1, 2011 at 8:25 AM, Andrei Savu <savu.andrei@gmail.com> wrote:
>> On Wed, Jun 1, 2011 at 5:55 PM, Tom White <tom.e.white@gmail.com> wrote:
>>> 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?
>>
>> I really like this idea of having different release cycles for
>> services and core. It should give us enough flexibility to evolve the
>> core while maintaining just a subset of services in sync. We could
>> create a version numbering convention in order to avoid confusions
>> (e.g. Whirr Hadoop 0.5.x should always work with Whirr Core 0.5.y).
>>
>> It sounds like we will need some sort of tool for installing supported
>> services while using the CLI (elasticsearch is using something like
>> this). When using Whirr as library maven should be enough to handle
>> multiple versions and releases.
>>
>> +1 for having different releases for core and services as part of the
>> same project. This should help as build a larger community, be more
>> dynamic and increase the number of supported services.
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message