You do it however you feel is right, I don't feel like making any rules. I'm only asking you to consider the downstream user, if you choose not to then that's fine too.
Regards Scott On 20/02/2010, at 1:17 AM, Adrian Crum wrote: > Who suggested removing them? They are being moved to a different package. As > I already said - an existing installation can do a simple search and replace > to accommodate that. Plus, as I have also pointed out, changes like this have > been done in the past with no regard to release version compatibility. > > So, yes - this is a thread hijack. What I am suggesting has been done many > times before with no warning or discussion, but now it has become an issue. > Why should the change I'm proposing follow some new rule? Are you going to > make that rule retroactive? How many files in the trunk have been > changed/moved/deleted in a backwards-incompatible way since the R 9.04 branch? > > If you want to make new rules, then fine - start a new thread for that. And > make sure the new rules apply to the next release, not to the trunk. > > For now, it would help if we could stay on subject. > > -Adrian > > > --- On Sat, 2/20/10, Scott Gray <[email protected]> wrote: > >> From: Scott Gray <[email protected]> >> Subject: Re: Discussion: New package org.ofbiz.base.types >> To: [email protected] >> Date: Saturday, February 20, 2010, 12:07 AM >> I wouldn't say it was hijacked, >> deprecating classes vs. removing them seems pretty pertinent >> to the discussion and has a direct impact on version >> compatibility. >> >> Regards >> Scott >> >> On 20/02/2010, at 12:47 AM, Adrian Crum wrote: >> >>> This thread is in no way similar to moving a >> component. I'm suggesting moving a handful of Java classes >> to a new package. Unfortunately, what should have been a >> discussion about that change has been hijacked into a >> different discussion about release strategy and release >> version compatibility. >>> >>> -Adrian >>> >>> --- On Fri, 2/19/10, BJ Freeman <[email protected]> >> wrote: >>> >>>> From: BJ Freeman <[email protected]> >>>> Subject: Re: Discussion: New package >> org.ofbiz.base.types >>>> To: [email protected] >>>> Date: Friday, February 19, 2010, 11:30 PM >>>> wading in late, >>>> I believe the idea behind component was that it >> could be >>>> located and >>>> that was transparent. Like ecommerce got moved but >> it does >>>> not effect >>>> the operation of it. >>>> So any idea you have should follow that concept. >>>> >>>> Adrian Crum sent the following on 2/19/2010 10:07 >> PM: >>>>> --- 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
