Versioning and Upgrades

Upgrading Kipchak

Introduction

This page lists all the breaking changes introduced by each major version.

There are multiple ways to mitigate these changes, but the safest is to follow the starter project structure and upgrade step by step.

For versioning information, please see Versioning.

Upgrading from 1.x to 2.x

Upgrading from version 1.x to 2.x is a major release and has breaking changes.

It introduces interfaces for writing Drivers and Middleware and slightly changes the bootstrapping process.

Changes include:

  • Package name has changed from mamluk/kipchak to kipchak/core
  • Namespace has changed from Mamluk\Kipchak to Kipchak\Core
  • The project has been restructured to be more modular and has thus introduced:
  • Interfaces have been added to make it easier to write drivers and middlewares
  • The starter repository has been updated to use the new structure
  • Middlewares and Drivers now initialise with a single method and must be registered in middlewares/middlewares.php and drivers/drivers.php, respectively.
  • The base controller name has changed from Slim to Base and now ONLY includes the Logger driver.
  • Bootstrapping has been simplified for faster boot times.
  • The html/index.php entrypoint now uses FrankenPHP's worker mode.
  • You will have to update your composer.json file to use just those drivers and middlewares you need, as opposed to everything that was bundled into the core before.
  • Instead of using $container->get() to now get any dependencies in the container, use Driver::get().

Upgrading from 0.x to 1.x

Upgrading from version 0.x to 1.x is a major release and has breaking changes.

This means:

  • Support for PHP 8.4.
  • You will have to manually use the session management middleware as it has been removed from the core.
  • Zircote Swagger is now part of the core.
  • Doctrine has been upgraded to version 3.5+. This may result in breaking changes, especially:
    • for migrations and if you were using / extending some core Doctrine capabilities without specifying return types.
    • for the Doctrine ORM if you use Doctrine proxies (in this case you will need to remove the proxies.sh script from your bin/ folder and remove its execution from your Dockerfile). Proxies are generated automatically in 3.5+ at runtime as needed.
  • Upgrade to the new Doctrine cli (which is available in the bin/ folder of the starter project) created for Kipchak. The prebuilt cli command was removed in Doctrine 3.5.
Previous
Versioning