The rationale is that if package renames are the only operation
performed on the code is contained in their own versions, then
external configuration code can use that Version as the
"seam" between the old and new package name, without introducing new
functional changes. A context where this is useful is a legacy
production app with a long-term persistent objects which are part of
the package being renamed.
Also simply for cleaner and clearer delineation in the code history,
and preserving the ability to "diff" the code and see the _other_ code
you want to change along with the rename, not mixed in with all the
rename changes.
- Chris
On Fri, Jun 15, 2018 at 3:17 PM Eliot Miranda <
[hidden email]> wrote:
>
>
>
> On Fri, Jun 15, 2018 at 12:15 PM, Eliot Miranda <
[hidden email]> wrote:
>>
>> Hi All, Hi Bert,
>>
>> if one tries to rename a modified package in the Monticello browser one is told one can only rename unmodified packages. Why? AFAICS it should "just work". What am I missing?
>
>
> Indeed, I just bypassed the check in the debugger and did the rename of my modified package and I can see no ill effects. I understand that the package gets marked as modified when renamed, and that hence that fresh indication of modification won't show up because the package is already modified, but so what? So this seems to me like an unnecessary restriction.
>
>>
>> _,,,^..^,,,_
>> best, Eliot
>
>
> _,,,^..^,,,_
> best, Eliot
>
Locked
