well so much for backward compatibility. (RANT)

[BJ Freeman]

I just plugged my code from ver 4.0 into trunk
guess what
none of it works.
so what happend to depreciating then removing, based on releases.
Sure ver 1.5 has lots of neat things.
but shouldn't we try to conserve as much of the programming effort as we
can.
Why not add the same functions and method and leave the 1.4 compatibility

[David E Jones]

Could you be more specific, ie what is broken and what errors are you  
getting?

-David


On Nov 19, 2007, at 12:45 AM, BJ Freeman wrote:

> I just plugged my code from ver 4.0 into trunk
> guess what
> none of it works.
> so what happend to depreciating then removing, based on releases.
> Sure ver 1.5 has lots of neat things.
> but shouldn't we try to conserve as much of the programming effort  
> as we
> can.
> Why not add the same functions and method and leave the 1.4  
> compatibility

[BJ Freeman]

Well I guess I am not fair.
I pulled the framework into Ver 4.0 which is compiling using 1.4.
So I guess even though I don't use the 1.5 stuff, it will error.
and since the 1.4 compiler is not able to evaluate 1.5
I am getting errors.
ServiceUtil.returnError-> method returnError(string) is not defined.
UtilXml.childElementList-> childElementList(list) in UtilXml is not
applicable for agurments (element, string)
are a couple.



David E Jones sent the following on 11/18/2007 11:52 PM:

>
> Could you be more specific, ie what is broken and what errors are you
> getting?
>
> -David
>
>
> On Nov 19, 2007, at 12:45 AM, BJ Freeman wrote:
>
>> I just plugged my code from ver 4.0 into trunk
>> guess what
>> none of it works.
>> so what happend to depreciating then removing, based on releases.
>> Sure ver 1.5 has lots of neat things.
>> but shouldn't we try to conserve as much of the programming effort as we
>> can.
>> Why not add the same functions and method and leave the 1.4 compatibility
>

[SkipDever]

I agree with BJ.  Backward compatibility should be a LAW only broken for a
very compelling reason, note a goal.

Skip

-----Original Message-----
From: BJ Freeman [mailto:[hidden email]]
Sent: Sunday, November 18, 2007 11:46 PM
To: [hidden email]
Subject: well so much for backward compatibility. (RANT)


I just plugged my code from ver 4.0 into trunk
guess what
none of it works.
so what happend to depreciating then removing, based on releases.
Sure ver 1.5 has lots of neat things.
but shouldn't we try to conserve as much of the programming effort as we
can.
Why not add the same functions and method and leave the 1.4 compatibility

[Adrian Crum]

Skip,

If that was a law, then the project would never move forward. OFBiz will take advantage of new
technologies when they appear. Sometimes that means backward compatibility will take a back seat.

-Adrian

skip@thedevers wrote:

> I agree with BJ.  Backward compatibility should be a LAW only broken for a
> very compelling reason, note a goal.
>
> Skip
>
> -----Original Message-----
> From: BJ Freeman [mailto:[hidden email]]
> Sent: Sunday, November 18, 2007 11:46 PM
> To: [hidden email]
> Subject: well so much for backward compatibility. (RANT)
>
>
> I just plugged my code from ver 4.0 into trunk
> guess what
> none of it works.
> so what happend to depreciating then removing, based on releases.
> Sure ver 1.5 has lots of neat things.
> but shouldn't we try to conserve as much of the programming effort as we
> can.
> Why not add the same functions and method and leave the 1.4 compatibility
>
>

[David E Jones]

I still haven't seen any response on my question, basically any  
evidence of non-backward compatibility or the nature of the problem BJ  
is seeing.

Just like in "The Princess Bride" movie: "Rodents Of Unusual Size, I  
don't believe they exist". ;)

BJ: please send along the errors you are seeing so this can be easily  
reviewed by a larger audience (rather than people having to try to  
reproduce what you're doing, which is hard with custom code!).

-David


On Nov 19, 2007, at 12:03 PM, skip@thedevers wrote:

> I agree with BJ.  Backward compatibility should be a LAW only broken  
> for a
> very compelling reason, note a goal.
>
> Skip
>
> -----Original Message-----
> From: BJ Freeman [mailto:[hidden email]]
> Sent: Sunday, November 18, 2007 11:46 PM
> To: [hidden email]
> Subject: well so much for backward compatibility. (RANT)
>
>
> I just plugged my code from ver 4.0 into trunk
> guess what
> none of it works.
> so what happend to depreciating then removing, based on releases.
> Sure ver 1.5 has lots of neat things.
> but shouldn't we try to conserve as much of the programming effort  
> as we
> can.
> Why not add the same functions and method and leave the 1.4  
> compatibility
>

[SkipDever]

Adrian

You can take advantage of new technology without sacrificing backward
compatibility, usually.

On the other hand, I personally think there are valid reasons for breaking
most if not all laws.

I cannot imagine why you couldn't depricate some class or method and leave
it, if for no other reason than to remind yourself to design you're code
better in the future before it is released.

Skip

-----Original Message-----
From: Adrian Crum [mailto:[hidden email]]
Sent: Monday, November 19, 2007 11:08 AM
To: [hidden email]
Subject: Re: well so much for backward compatibility. (RANT)


Skip,

If that was a law, then the project would never move forward. OFBiz will
take advantage of new
technologies when they appear. Sometimes that means backward compatibility
will take a back seat.

-Adrian

skip@thedevers wrote:

> I agree with BJ.  Backward compatibility should be a LAW only broken for a
> very compelling reason, note a goal.
>
> Skip
>
> -----Original Message-----
> From: BJ Freeman [mailto:[hidden email]]
> Sent: Sunday, November 18, 2007 11:46 PM
> To: [hidden email]
> Subject: well so much for backward compatibility. (RANT)
>
>
> I just plugged my code from ver 4.0 into trunk
> guess what
> none of it works.
> so what happend to depreciating then removing, based on releases.
> Sure ver 1.5 has lots of neat things.
> but shouldn't we try to conserve as much of the programming effort as we
> can.
> Why not add the same functions and method and leave the 1.4 compatibility
>
>

[cjhowe]

IIRC, immediately after stating that, the protagonist was attacked by one ;-)

----- Original Message ----
From: David E Jones <[hidden email]>
To: [hidden email]
Sent: Monday, November 19, 2007 1:22:33 PM
Subject: Re: well so much for backward compatibility. (RANT)


I still haven't seen any response on my question, basically any  
evidence of non-backward compatibility or the nature of the problem BJ
 
is seeing.

Just like in "The Princess Bride" movie: "Rodents Of Unusual Size, I  
don't believe they exist". ;)

BJ: please send along the errors you are seeing so this can be easily  
reviewed by a larger audience (rather than people having to try to  
reproduce what you're doing, which is hard with custom code!).

-David


On Nov 19, 2007, at 12:03 PM, skip@thedevers wrote:

> I agree with BJ.  Backward compatibility should be a LAW only broken
 

> for a
> very compelling reason, note a goal.
>
> Skip
>
> -----Original Message-----
> From: BJ Freeman [mailto:[hidden email]]
> Sent: Sunday, November 18, 2007 11:46 PM
> To: [hidden email]
> Subject: well so much for backward compatibility. (RANT)
>
>
> I just plugged my code from ver 4.0 into trunk
> guess what
> none of it works.
> so what happend to depreciating then removing, based on releases.
> Sure ver 1.5 has lots of neat things.
> but shouldn't we try to conserve as much of the programming effort  
> as we
> can.
> Why not add the same functions and method and leave the 1.4  
> compatibility
>

[David E Jones]

Exactly, hence my solicitation. It's not that I don't trust that BJ  
ran into something, I'm just wondering what it is he ran into...

-David


On Nov 19, 2007, at 12:42 PM, Chris Howe wrote:

> IIRC, immediately after stating that, the protagonist was attacked  
> by one ;-)
>
> ----- Original Message ----
> From: David E Jones <[hidden email]>
> To: [hidden email]
> Sent: Monday, November 19, 2007 1:22:33 PM
> Subject: Re: well so much for backward compatibility. (RANT)
>
>
> I still haven't seen any response on my question, basically any
> evidence of non-backward compatibility or the nature of the problem BJ
>
> is seeing.
>
> Just like in "The Princess Bride" movie: "Rodents Of Unusual Size, I
> don't believe they exist". ;)
>
> BJ: please send along the errors you are seeing so this can be easily
> reviewed by a larger audience (rather than people having to try to
> reproduce what you're doing, which is hard with custom code!).
>
> -David
>
>
> On Nov 19, 2007, at 12:03 PM, skip@thedevers wrote:
>
>> I agree with BJ.  Backward compatibility should be a LAW only broken
>
>> for a
>> very compelling reason, note a goal.
>>
>> Skip
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:[hidden email]]
>> Sent: Sunday, November 18, 2007 11:46 PM
>> To: [hidden email]
>> Subject: well so much for backward compatibility. (RANT)
>>
>>
>> I just plugged my code from ver 4.0 into trunk
>> guess what
>> none of it works.
>> so what happend to depreciating then removing, based on releases.
>> Sure ver 1.5 has lots of neat things.
>> but shouldn't we try to conserve as much of the programming effort
>> as we
>> can.
>> Why not add the same functions and method and leave the 1.4
>> compatibility
>>
>
>
>
>

[BJ Freeman]

I apologize for causing such a ruckus
First of all I had a long day before doing this.
So it did not dawn on me that the errors were normal.
that instead of dropping framework from the trunk into my ver 4.0
I should drop my application into the current trunks.

as I said below, I tried using 1.4 compiler on code the includes 1.5
additions.
the 1.4 compiler is just not able to evaluate 1.5 syntax.


BJ Freeman sent the following on 11/19/2007 12:10 AM:

> Well I guess I am not fair.
> I pulled the framework into Ver 4.0 which is compiling using 1.4.
> So I guess even though I don't use the 1.5 stuff, it will error.
> and since the 1.4 compiler is not able to evaluate 1.5
> I am getting errors.
> ServiceUtil.returnError-> method returnError(string) is not defined.
> UtilXml.childElementList-> childElementList(list) in UtilXml is not
> applicable for agurments (element, string)
> are a couple.
>
>
>
> David E Jones sent the following on 11/18/2007 11:52 PM:
>> Could you be more specific, ie what is broken and what errors are you
>> getting?
>>
>> -David
>>
>>
>> On Nov 19, 2007, at 12:45 AM, BJ Freeman wrote:
>>
>>> I just plugged my code from ver 4.0 into trunk
>>> guess what
>>> none of it works.
>>> so what happend to depreciating then removing, based on releases.
>>> Sure ver 1.5 has lots of neat things.
>>> but shouldn't we try to conserve as much of the programming effort as we
>>> can.
>>> Why not add the same functions and method and leave the 1.4 compatibility
>
>
>

[SkipDever]

Way too funny.  But, then again, a good depate on these kinds of issues is a
splendid way to waste time.

Skip

-----Original Message-----
From: BJ Freeman [mailto:[hidden email]]
Sent: Monday, November 19, 2007 12:03 PM
To: [hidden email]
Subject: Re: well so much for backward compatibility. (RANT)


I apologize for causing such a ruckus
First of all I had a long day before doing this.
So it did not dawn on me that the errors were normal.
that instead of dropping framework from the trunk into my ver 4.0
I should drop my application into the current trunks.

as I said below, I tried using 1.4 compiler on code the includes 1.5
additions.
the 1.4 compiler is just not able to evaluate 1.5 syntax.


BJ Freeman sent the following on 11/19/2007 12:10 AM:

> Well I guess I am not fair.
> I pulled the framework into Ver 4.0 which is compiling using 1.4.
> So I guess even though I don't use the 1.5 stuff, it will error.
> and since the 1.4 compiler is not able to evaluate 1.5
> I am getting errors.
> ServiceUtil.returnError-> method returnError(string) is not defined.
> UtilXml.childElementList-> childElementList(list) in UtilXml is not
> applicable for agurments (element, string)
> are a couple.
>
>
>
> David E Jones sent the following on 11/18/2007 11:52 PM:
>> Could you be more specific, ie what is broken and what errors are you
>> getting?
>>
>> -David
>>
>>
>> On Nov 19, 2007, at 12:45 AM, BJ Freeman wrote:
>>
>>> I just plugged my code from ver 4.0 into trunk
>>> guess what
>>> none of it works.
>>> so what happend to depreciating then removing, based on releases.
>>> Sure ver 1.5 has lots of neat things.
>>> but shouldn't we try to conserve as much of the programming effort as we
>>> can.
>>> Why not add the same functions and method and leave the 1.4

compatibility
>
>
>

[jonwimp]

BJ,

Not too sure which direction you applied from, trunk to release or release to trunk?

I don't believe backward compatibility is relevant here.

Release 4.0 is not required to be backward compatible with trunk, nor vice versa.

The trunk is a special branch. It forges ahead at high speed. All that is really required for
*any* revision in trunk is this: the ability to compile and function correctly (bugs aside).

However, in some cases, special consideration and extra effort could be spent on maintaining
backward compatibility, even in trunk revisions. In general, cases like say "many folks are using
JPublish" (not really true, just illustration), then the trunk would keep JPublish codes.

If you're into computer hardware, consider backward compatibility in the AGP (graphics port). An
AGP 8 slot can accommodate an AGP 8 or older (say AGP 4) graphics card. The analogy ties to the
release branch 4.0, where 4.x is compatible with 4.y.

Consider the trunk as the forefront of graphics card slots. The PCIe slot is completely
incompatible with AGP graphics cards. For the sake of progress, the PCIe inventors couldn't wait
for AGP graphics cards to all die off.

The jump from AGP to PCIe is too substantial to make backward compatibility possible. Same for 1.4
to 1.5, I believe. Sometimes, it takes so much to wait up for signs and omens to ratify the jump,
it's easier to just make the jump and be done wit it.

Jonathon

BJ Freeman wrote:

> I just plugged my code from ver 4.0 into trunk
> guess what
> none of it works.
> so what happend to depreciating then removing, based on releases.
> Sure ver 1.5 has lots of neat things.
> but shouldn't we try to conserve as much of the programming effort as we
> can.
> Why not add the same functions and method and leave the 1.4 compatibility
>
>