You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the system module, we have files to support an upgrade from XOOPS even. Technically, there is no overlap in supported PHP versions with those old ImpressCMS versions. I propose we remove the upgrade options for everything that is older than 1.4.2 (first version to support PYP 7.4, which is our minimal version right now).
Reason : less code to maintain and less migration paths to test. If older versions need to upgrade first to 1.4.2 before going to 2.0.2, we have less differences in what comes in from a system module point of view.
The text was updated successfully, but these errors were encountered:
We can definitely do without the /upgrade folder that handles XOOPS upgrades and then migration to ImpressCMS, and the ICMS1.0 to 1.1 upgrade. At this point, we're only going to be dealing with people upgrading from one version of ImpressCMS to another.
The next major hurdle is when we went from our original releases to the IPF conventions in 1.3. Upgrading from versions prior to that to ones since then are going to involve more than a one-step upgrade can handle.
Finally, the removal of /class, /kernel, and functions that had been replaced and deprecated affects the last stage of upgrading. I think 1.4.2 was the version where those began to be removed (there was enough notice and time to plan and prepare).
It is rather nostalgic to look back at those upgrade files and see where we've been and what we've done. Other than that, they don't serve much other purpose.
In the system module, we have files to support an upgrade from XOOPS even. Technically, there is no overlap in supported PHP versions with those old ImpressCMS versions. I propose we remove the upgrade options for everything that is older than 1.4.2 (first version to support PYP 7.4, which is our minimal version right now).
Reason : less code to maintain and less migration paths to test. If older versions need to upgrade first to 1.4.2 before going to 2.0.2, we have less differences in what comes in from a system module point of view.
The text was updated successfully, but these errors were encountered: