At 04:14 PM 11/10/00 -0500, Paul Kinnucan wrote:
>At 07:46 PM 11/10/00 +0000, you wrote:
>>>>> Paul Kinnucan <[EMAIL PROTECTED]> 10-Nov-00 7:09:59 PM >>>
>>
>>>Imagine this scenario. A user replaces the standard
>>>jde-compile.el with your version. I make a change to
>>>the standard jde-compile.el in the next release.
>><snip>
>>
>>Absolutely. That's why I haven't actually asked you to put it in JDE
>>yet.
>>
>
>This problem arises precisely because I have not included jde-compile.el in
I meant to say I have not yet included your version of jde-compile.el
>the release. You are distributing one version; I am distributing another.
>This is inherently evil.
>
>>When the people testing it get back to me I'll send you a nicely
>>packaged, seperate, file in the way you require.
>>
>
>I'm suggesting you do this right from the beginning.
>
I mean distribute your improvements as a uniquely named file containing only
your code. (I'm assuming that your code is standalone and does not entail
changes to the existing jde-compile code.)
>>
>>>>Trouble is that if you have any relative paths set then it won't
>>>>compile properly.
>>>I can't accept changes that break existing functionality.
>>
>>So how do *you* intend to deliver relative paths? As soon as you say
>>"relative paths are resolved to root X" then you break the existing
>>functionality.
>>
>>And what you're saying is, unless I take the relative stuff out, or
>>do all the work on the rest of the JDE, I can't contribute my
>>alternative compile stuff?
>>
>
>You can contribute the stuff that has to do with compile option settings
>and contribute the path stuff later as part of a general relative path
release.
>
Or you could include your relative path stuff in the separate compile file
and then wait until the general path release to incorporate your compile stuff
into the JDE distribution.
- Paul
