Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 59721 invoked from network); 4 Apr 2005 19:08:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Apr 2005 19:08:26 -0000 Received: (qmail 32828 invoked by uid 500); 4 Apr 2005 19:08:21 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 32791 invoked by uid 500); 4 Apr 2005 19:08:21 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 32776 invoked by uid 99); 4 Apr 2005 19:08:21 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from chi.mobile-health-diary.com (HELO chi.mobile-health-diary.com) (128.241.244.71) by apache.org (qpsmtpd/0.28) with SMTP; Mon, 04 Apr 2005 12:08:21 -0700 Received: (qmail 19184 invoked from network); 4 Apr 2005 19:08:19 -0000 Received: from ool-43560634.dyn.optonline.net (HELO ?10.0.1.33?) (geir@67.86.6.52) by b014.internal.mobile-health-diary.com with SMTP; 4 Apr 2005 19:08:19 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <4e42beae20f36a8398a33146c02487c2@gluecode.com> References: <424EFD61.2080601@apache.org> <4251122A.4020000@optusnet.com.au> <4e42beae20f36a8398a33146c02487c2@gluecode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Geir Magnusson Jr Subject: Re: Incompatible API change in Configuration Date: Mon, 4 Apr 2005 15:08:21 -0400 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.619) X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Apr 4, 2005, at 2:17 PM, Dain Sundstrom wrote: > I personally think this is way way way too early to be worried about > binary compatability between configuration objects build with pervious > releases and builds. Also, are you taking only about the official M1, > M2 and M3 releases or builds from code? > > What do you, the community, think about us spending time thinking > about binary compatibility between milestone releases? I hate milestone releases and wish we would switch to 0.x leading to 1.0 :) I think that breaking binary compatibility at this point should be for a darn good reason, and only after discussion - we want to get into the habit to avoid it at all costs. geir > > -dain > > -- > Dain Sundstrom > Chief Architect > Gluecode Software > 310.536.8355, ext. 26 > > On Apr 4, 2005, at 3:08 AM, Gianny Damour wrote: > >> My bad :( >> >> I must admit that this is a side effect that I have not duly >> considered. I considered the source and binary compatibility and I >> missed this serialization specific incompatibility. >> >> Gianny >> >> On 3/04/2005 6:15 AM, Jeremy Boynes wrote: >> >>> On 3/22 in revision 158589 the API for Configuration changed in that >>> the return type from getConfigurationClassLoader() changed from >>> ClassLoader to a ConfigurationClassLoader. This means all >>> configurations built before then are now inoperable with the current >>> tree as the attribute type in the persisted GBeanData does not match >>> the new signature. >>> >>> I can't find any discussion on the list around then that would alert >>> users to this change. It is critical that we let people know when >>> this kind of change is made. >>> >>> -- >>> Jeremy >>> > > -- Geir Magnusson Jr +1-203-665-6437 geir@gluecode.com