Hi,
just to let you know:
If one develops a project in Pharo 7 (or before) including a manifest with
banned rules this may lead to
trouble in upcoming Pharo 8.
Within the manifest you will find methods referencing "RGPackage" class:
"code-critics"
ruleRBLiteralArrayContainsCommaRuleV1FalsePositive
^ #(#(#(#RGPackage #(#'Funny-App'))
#'2019-06-02T17:05:15.359384+02:00') )
If you load the code into latest Pharo 8 it is not possible to browse the
manifest class in Calypso without errors
as RGPackage class is missing in Pharo 8.
This goes back to a PR from Pavel:
https://github.com/pharo-project/pharo/pull/3226 to consolidate and
rename RGPackage into RGPackageDefinition.
I support the PR - but not the way how it is done as it does not consider
keeping and deprecating the old RGPackage
class.
For sure one can easily adopt the Manifest methods by replacing #RGPackage with
#RGPackageDefinition - but be aware
that accidentially or not we add more and more burden especially to new users
and future migrators.
IMHO we should "deprecate" and keep classes around at least one pharo version
iteration whenever possible.
(see also the deprecation guide
http://forum.world.st/Deprecation-guide-for-methods-classes-and-packages-td5085081.html)
We could have RGPackageDefinition as the new class, and keep the old class
RGPackage as a subclass of RGPackageDefinition
in a "Deprecated80" package so we can easily remove it with the start of the P9
iteration.
I also wonder why we still have the "Deprecated70" package around in latest P8
image and why we do not remove it as usual
and just start a fresh "Deprecated80" package. It was a simple scheme and
worked in the past without much hazzle.
Last time this was asked there was a discussions about a possible migration
tool - but so far without any visible progress
to my knowledge. Even if such a tool exists it could use the "Deprecated70"
package even after removal by just loading it...
Thanks
T.
