On Tue September 8 2009 12:58:15 pm Sergey Beryozkin wrote: > Ok, I'd prefer to merge Revision 811687 to 2.2.x but have only JAXRS > related changes commited to 2.2.x, with Aegis related ones (including > updates to AegisJSONProvider) being left out. Dan, would you agree ?
Yep. I agree. The major changes that may affect people should just stay on trunk. It may mean a little more work to get that revision merged back, but it's definitely best to do so. Dan > > cheers, Sergey > > ----- Original Message ----- > From: "Benson Margulies" <[email protected]> > To: <[email protected]> > Sent: Tuesday, September 08, 2009 5:44 PM > Subject: Re: Merging Aegis updates to 2.2.x > > > Well. You asked me to tackle the collection issues. I looked into them, > > and concluded that radical surgery on Aegis was needed. And that happened > > after I had done radical surgery to introduce flat='true'. > > > > Now, all of this should be compatible. However, I'm not impressed with > > the test coverage we have, based on previous complaints of Aegis > > compatibility issues. My conservative inclination is to say that this > > stuff is not backporting, and 2.2 JAX-RS+Aegis is what it is, and will > > only change for 2.3. On the other extreme, you and Dan could backport all > > the pending Aegis changes: flat='true' and also the changes for generics > > that I made to try to make JAX-RS work better. And, if by some chance > > someone undertakes 'unqualified', that will be yet another layer of > > complex changes. > > > > All of this highlights a tension between 'do development in trunk and > > merge back' and 'make radical changes in trunk.' Dan? > > > > On Tue, Sep 8, 2009 at 12:04 PM, Sergey Beryozkin <[email protected]>wrote: > >> Hi Benson > >> > >> Revision 811687 contains both Aegis and JAXRS changes so I'd like to get > >> it merged to 2.2.x... > >> Can you let me know what other Aegis-related changes need to be merged > >> to 2.2.x first before the revision 811687 can be merged to 2.2.x and > >> compiled there ? > >> thanks, Sergey > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
