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.
Locked
