Next release will be v5

[JohnRDOrazio]

Ever since starting to apply static analysis to the project, I realized that I really needed to define classes to represent the JSON data structures, so that the static analyzer could understand the precise shape of arrays and objects, and understand the types associated with every piece of data. Creating all these classes is fundamentally bringing about a lot of refactoring of the codebase. We even refactored all references to festivity, to liturgical_event, to avoid any confusion between festivity as a generic term for a celebration whatever the liturgical grade, and celebrations with a liturgical grade of feast (see issue #239). We are also doing a few other refactors such as in issue #319.

The next release therefore cannot be a minor release, but because of the breaking changes will have to be a major release. Even though not a lot of new functionality is being introduced, we however want to avoid confusion in releasing a minor version with so much refactoring and a few breaking changes. The frontend interface for creating liturgical calendars will also need to be updated to match the new schemas and property names. So basically, until version 5 is released and the frontend interface is updated to match, the https://litcal-staging.johnromanodorazio.com will not be working correctly. Since some of the refactoring on the API development branch has already been pushed to the online server instance, the staging frontend is currently non functional, until it gets an update. However the stable branch frontend at https://litcal.johnromanodorazio.com should still work.

[JohnRDOrazio]

Some more of the refactoring that has been introduced in the now released v5 of the API, is compliance with PSR standards (PHP standard recommendations), which set out some base interfaces and methods that applications should adopt when it comes to HTTP messaging and error logging. I had initially handled all of the request / response interaction manually, simply reading data from the incoming streams and sending out streams of data. Now with v5 the codebase follows PSR standards, making it more recognizable and more compatible with other frameworks such as Laravel or Symfony. Rather than adopt a complex framework like Laravel or Symfony, I think it's enough for now to just adhere to the standards and implement the interfaces, which also makes for clearer and more coherent code patterns (I wasn't always consistent in the previous versions of the codebase with class properties and methods sometimes being defined as static, sometimes as instance properties and methods, but with v5 by following the standards all that mess is now much cleaner).