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" <[email protected]> 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 <[email protected]> wrote: >> On Wed, Jun 1, 2011 at 5:55 PM, Tom White <[email protected]> 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. >>
