Re: River and Backward Compatibility

Mike Morris wrote:
> Dan Creswell wrote:
>  > Following Jim's advice, I'm pushing this discussion over to our other
> lists.
>  >
>  > Any thoughts from the community on how much backward compatibility is
>  > desirable in the first releases from River much appreciated.
>
> Respectfully, I have to disagree with those who have said "chuck
> backwards compatibility overboard."  Anybody who has a significant
> deployed installation (I don't) will have nightmares at the thought.  My
> fear is less about compiled code than about all the deployment scripts,
> permissions files, etc., that will need to get modified along the line
> in a production setup (assuming, too, that I've understood the framing
> of Dan's original question.)

It is my impression Dan's question was not related to compatibility with
regard to the stuff you are talking about. IMHO it was merely related at
this stage to for example the layout of the distribution and whether
people would be able to hook in PSEPro for a particular type of
persistent Outrigger. Changing the layout could mean people have to
perform some work in order to integrate the distribution into their
development/production environment, etc.

> Important to remember, IMHO, that the primary purpose of this next
> release is to get the River community working within the Apache
> framework, adapting the long legacy of Jini Community ways of thought,
> ideas, etc. to Apache norms and processes.
>
> My 2c-worth: change the absolute _minimum_ that /must/ be changed
> (package names, what else?) to get the release out.  Nothing else.  As
> close as possible to 100% backwards compatibility.
>
> Bear in mind that Jim Hurley has also proposed a follow-up release
> fairly soon after the first River release (IIRC November sometime?);
> /that/ would be the point to start making incompatible changes.  i.e.
> This release is about process, not about the codebase or packaging.

You are right, although no decision has been made about API
compatibility (com.sun -> org.apache) for the second release, but I
doubt whether such a drastic change is opportune given the fact there
are a lot of diffs against the current codebase of which we must decide
whether it will be incorporated or not.
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]