--- On Fri, 2/19/10, Adam Heath <[email protected]> wrote: > From: Adam Heath <[email protected]> > Subject: Re: Discussion: New package org.ofbiz.base.types > To: [email protected] > Date: Friday, February 19, 2010, 9:57 PM > Adrian Crum wrote: > > --- On Fri, 2/19/10, Scott Gray <[email protected]> > wrote: > > > >> From: Scott Gray <[email protected]> > >> Subject: Re: Discussion: New package > org.ofbiz.base.types > >> To: [email protected] > >> Date: Friday, February 19, 2010, 9:45 PM > >> On 19/02/2010, at 10:10 PM, Adrian > >> Crum wrote: > >> > >>> --- On Fri, 2/19/10, Adam Heath <[email protected]> > >> wrote: > >>>> From: Adam Heath <[email protected]> > >>>> Subject: Re: Discussion: New package > >> org.ofbiz.base.types > >>>> To: [email protected] > >>>> Date: Friday, February 19, 2010, 8:56 PM > >>>> Adam Heath wrote: > >>>>> Adrian Crum wrote: > >>>>>> In the org.ofbiz.base.util package > there > >> are > >>>> interfaces and classes that don't really > belong > >> there - they > >>>> are data types, not utility classes. It > would be > >> nice if we > >>>> could create a new package to contain > basic data > >> types: > >>>> org.ofbiz.base.types. The new package > would > >> contain things > >>>> like: Appender, DateRange, Factory, > Range, > >> ComparableRange, > >>>> TimeDuration, etc. > >>>>>> The org.ofbiz.base.util package > could be > >>>> (informally) limited to classes that > follow the > >> utility > >>>> class pattern (only static methods, > private > >> constructor, > >>>> etc). > >>>>>> What do you think? > >>>>> org.ofbiz.base.lang > >>>> Where ever they get moved to, you need to > check > >> for classes > >>>> that > >>>> existed in a previous release, and make > certain > >> they still > >>>> exist, and > >>>> just extend the classes that were copied > to the > >> new > >>>> location. Then, > >>>> add deprecation to the old versions. > >>> I probably wouldn't do that. I understand what > you're > >> getting at, but it adds unnecessary code and > complexity to > >> the project. Anyone wanting to upgrade from a > release who > >> used the affected classes could do a simple search > and > >> replace on the import statements. > >>> Things like this have been moved around > before. > >> I agree with Adam, in an ideal world, one would be > able to > >> uplift their hot-deploy components from 9.04 and > drop them > >> into 10.x without any issues. We're probably > still a > >> long way from that but I don't think we should > make things > >> any harder for the user than we need to. > > > > So, where does that process end? Should hot-deploy > components from 10.x drop into 11.x without any issues? That > would require maintaining code from 9.04 AND 10.x in 11.x. > > No. > > Stuff from 9.04 should work without any changes in > 10.x. However, > there could be warnings issues for anything that isn't > being done in > an optimal way. > > This gives downstreams time to fix their 9.04 modules to > work properly > for 10.x, before we eventually release 11.x.
I have used patch files for that and it hasn't been a big issue. For example, my production deployment patch modifies start.properties. In revision 684377 that file was moved to another folder. So, I just updated my patch. I never expected that file's original location to be supported in future versions.
