RE: [higgins-dev] Changes to IdAS API

["Tom Doman" <TDoman@xxxxxxxxxx>]

Yeah, sense #2 is more what I had in mind.  A "last stable" build I think would be fine but I'm not opposed to pre-distribution of changes in a jar either.  I'm just looking for a way to try implementation before it's broadly published as:
1. a solid and prescribed interface
2. something all implementors should have already coded to

There may be other approaches to accomplish the same thing but I'm not picky about that, just that there's an orderly way we do it.

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 02/06/07 10:42 AM >>>
I think the term "pre-publish" is possibly being interpreted two different ways on this thread.
 
- In one sense (what I think Paul might be thinking), it would entail a message sent to the dev list specifying the changes about to occur, and some time elapsing where implementors could give their ok.  Then the interface changes would be committed (and the list notified), then the interface implementors/consumers could make their changes in a timely manner.
- In the sense I hear Tom talking about, the interface changes would be made, but not committed, or there would be some other lock-step mechanism whereby interface implementors/consumers would get the new interface jars, implement/update, and then give their ok, and then everything is committed within a fairly tight time window.  This would minimize broken integration points to nearly zero.
 
For sense #2 to work, we'd either need a set of "last stable" downloads (I think this would be easiest), or we'd have to pass around developer-built jars.  I don't like passing jars around because it means code changes are being done without a version control safety net.  
 
Do we want to move in the direction of creating a "last stable" build prior to making disruptive interface changes?  We might also need some indicator to those wishing to download that the state of integration is severely broken as we're making these kinds of interface changes (thus, they *really* should use the "last stable" code).
 
Jim

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 2/4/07 8:50 PM >>>
Thanks Paul, I think a pre-publish mechanism would also give us a chance to encounter implementation issues that may modify or invalidate the approach intended by a particular interface change.

Tom

>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 02/04/07 1:41 PM >>>
You're right Tom. We should do a better job of pre-publishing interface
changes that will affect other components. 

-Paul

> -----Original Message-----
> From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Tom Doman
> Sent: Saturday, February 03, 2007 10:08 PM
> To: Valery Kokhan; Higgins (Trust Framework) Project developer discussions
> Subject: Re: [higgins-dev] Changes to IdAS API
> 
> Is there a way we could get interface changes pre-published together with
> a chance for interface implementors to implement interface changes before
> they are forced to do so by a check-in?  I think interface implementors
> need a chance to plan for these in advance and\or bring up scheduling
> issues that may arise due to their own delivery requirements.
> 
> Tom
> 
> >>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 01/24/07 6:49 AM >>>
> I've been committed initial changes to IContextFactory and
> IdASRegistry proposed at
> http://wiki.eclipse.org/index.php/IdAS_Registry_and_Configuration .
> 
> However, the more I think of this the stronger is my filling that
> this proposal is not smart/flexible enough and probably we'll need to
> get back to this later.
> 
> Earlier today I've committed changes to IdAS API proposed last week
> and described at https://bugs.eclipse.org/bugs/show_bug.cgi?id=171295.
> 
> Valery
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev 
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev