Mailing-List: contact whirr-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: whirr-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of savu.andrei@gmail.com
 designates 209.85.220.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Oa456+tUScHAZlTDQrJ/umrJ9wHgE0TIggj288pShGRCQ3wHcn3RSFyzwh2iSscEQi
         MTxuMVAbQgy0mN587Qf7ne+416wzZWeOnEj2tKt5zx9Krbtksw7y3iMop/XM4+RM0/Pu
         nye38UoRH2TpF2E4MfiYfmmJVubfvY9+A3RFs=
MIME-Version: 1.0
In-Reply-To: <BANLkTikk95Eg-mnSYUwZFR2nxWagJxxYQg@mail.gmail.com>
References: <BANLkTimE7WwbMGNB14EyGTg7L_zuo5RKMQ@mail.gmail.com>
	<BANLkTik-kA84hGWAmdwyM2afuiWNfobPqQ@mail.gmail.com>
	<BANLkTim9fhLn0EtZjjEeUSZdZnxbLGF_vA@mail.gmail.com>
	<BANLkTinrqbzSp5xj38LDNyTZiUOHeoWD5Q@mail.gmail.com>
	<BANLkTikJ32OL4b8bZXWb9kW8PHkiV2BVMA@mail.gmail.com>
	<BANLkTikFZ_Xf--QHGCVt0L_PsRJnN7K5rA@mail.gmail.com>
	<BANLkTikiuKKorpnPit5SbtQbqp0w+kjToA@mail.gmail.com>
	<BANLkTikk95Eg-mnSYUwZFR2nxWagJxxYQg@mail.gmail.com>
Date: Wed, 1 Jun 2011 21:14:21 +0300
Message-ID: <BANLkTimh8mDOa7RbKsoDzz2186UcLUzx7g@mail.gmail.com>
Subject: Re: Contrib for new services
From: Andrei Savu <savu.andrei@gmail.com>
To: whirr-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e64754e4646db504a4aa7d71

--0016e64754e4646db504a4aa7d71
Content-Type: text/plain; charset=ISO-8859-1

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.
>>

--0016e64754e4646db504a4aa7d71--