I agree that we should keep the services in the same release. At the time of release we could run all the service integration tests and record which ones passed or failed. Failed tests wouldn't necessarily block a release, but if a service kept failing this would alert us to where more attention was needed.
Cheers, Tom On Wed, Jun 1, 2011 at 11:31 AM, Patrick Hunt <[email protected]> wrote: > Is something like thrift a good example here for comparison purposes? > http://svn.apache.org/viewvc/thrift/trunk/lib/ > They have a large number of different language implementations, a few > which have all the features, and many which support a subset (also in > terms of quality). As was suggested earlier in this thread we might > include some specific details in the docs for each of the services > detailing their level of support for various features. I think this > makes more sense than adding complexity to the build/runtime, also my > experience with the contrib approach is not favorable either. At some > later time we could work on separating things out, but for now it > would be more of a hindrance than a help. > > As suggested earlier I think streamlining the release process and > making more frequent releases would be a plus. > > Patrick > > On Wed, Jun 1, 2011 at 11:14 AM, Andrei Savu <[email protected]> wrote: >> 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. >>>> >> >
