Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-Id: <200403031843.BCJ88153@ms4.verisignmail.com>
Date: Wed, 3 Mar 2004 13:43:27 -0500
From: Luke Blanshard <luke@blanshard.us>
Subject: Re: [HiveMind] HiveMind ideas
To: "Howard M. Lewis Ship" <hlship@comcast.net>
Cc: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>From: "Howard M. Lewis Ship" <hlship@comcast.net>  
>> 
>> - I believe your placeholder for version checking is at the 
>> wrong level.
>>  I think versioning should be at the service interface level, not the
>> module level.  Isn't that how Eclipse does it?  What are your 
>> thoughts here?
>
>I'm pretty sure module level makes sense. Eclipse does it that way.

Right you are -- I misremembered.  However, let me expand a bit on my
theory.

A HiveMind module may supply lots of service interfaces.  Now, you
*might* want to manage all of these services' versions with a single
module-wide version -- as you have it.  But you might instead want to
manage their versions individually.  Why?  Well, otherwise your 10
stable services will appear to have changed incompatibly when you have
to bump your module's version number to satisfy your 1 rapidly changing
service.

I'm anticipating being able to specify the version number required when
wiring up a service, and when providing an implementation, with the
meanings for version numbers that Eclipse uses.  (Namely: a change to
the major number means a potentially incompatible change, and a change
to the minor number means backwards compatible.)

This seems useful to me, when trying to manage lots of independently
developed services, which is what I'm trying to do.

Luke

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org