I have compared CMakeLists.txt from before and after the rollback. I think some
changes introduced at a later stage was mistakenly removed by that rollback
In this section aroundset(CPACK_RPM_PACKAGE_LICENSE "CPL“) I found
differences:
Before rollback
set(CPACK_RPM_PACKAGE_VERSION ${ORX
It may be true that one can individually change the ooRexx location and version
by changing PATH such that the operating system can find the desired ooRexx in
that particular session that changed the PATH to point to a different ooRexx..
(This ability will not be lost if supporting update-atlern
it is great if it works but it is def old skool. This is the type of work
(evaluating code against releases of whatever) that anyone I work with (yes,
very young people, well compared to us) would do in a docker container.
I am a bit worried about the release schedule (what release schedule?) but
Dear Rony,
I understand that there is a use case for the „switch" and if someone with
sufficient expertise can bring it back to CMakeLists.txt without breaking other
things I have no objections but PLEASE do these changes only next week, ok? The
rollback broke a number of other things for the L
>
> I think some changes introduced at a later stage was mistakenly removed by
> that rollback
> Should not some of these settings be restored?
>
The roll back was done with a simple svn merge -c -11900,-11899 .
So I'd assume it to be correct .. can you please specify which change you
think was rol
> Am 07.04.2020 um 15:47 schrieb Erich Steinböck :
>
> I think some changes introduced at a later stage was mistakenly removed by
> that rollback
> Should not some of these settings be restored?
> The roll back was done with a simple svn merge -c -11900,-11899 .
> So I'd assume it to be correct
Dear Erich,
> The roll back was done with a simple svn merge -c -11900,-11899 .
> So I'd assume it to be correct .. can you please specify which change you
> think was rolled back incorrectly?
>
I have tried this out on CentOS and the reason I see 5.0.0-1 instead of
5.0.0-12054 is that lines
>
> The thing with not being able to revert to an older version of ooRexx is a
> murkier business. I do not think it is related to this change, I just had not
> noticed since I always build a newer version.
>
This is a just a thought, but is there ANY possibility that rexx -v reports
the wro
Compare to this, this is really weird (my highlighting)
[osboxes@fedora31 ~]$ rexx -v
Open Object Rexx Version 5.0.0 r12054
Build date: Apr 7 2020
Addressing mode: 64
Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
Copyright (c) 2005-2020 Rexx Language Association. All rights reser
