We are using git to maintain a product running on the Ignition platform. After a fetch Ignition tend to play hard and cause errors to happen. The user often need to restart both servers (redundancy, yes) to get things working again.
Consider revisiting the decision process that resulted in y’all trying to “maintain a product” on a version of Ignition that was known from the outset to NOT be a long-term-support version.
@SBL_MC What @pturmel is referencing is that only the odd numbered versions are supported long term by Ignition so 7.9, 8.1, next will be 8.3 etc. I did not know this until very recently tbch when a coworker told me informed me of this. I’m sure it’s somewhere on their site though.
The reason we stay put at 8.0.17 is that these systems does not have basic care. The newest and future systems is bought as and could be upgraded to 8.1 at no cost. I’m aware that running older versions is not the optimal solution.
Our git repository is built as a 8.0 project and cannot be fetched on to a 8.1 server without errors.
This graphic from 2019 shows the expected support lifetime of v8.0. (Very short. I don't recall the source article for that image, but it was widely discussed on this forum.)
This blog post from last year explains the extension of v7.9's active support phase to this June due to the length of time between v7.9's release and v8.1:
A similar effect will happen when v8.2 comes out. It will be glorious--new features galore, enabled by architecture changes that would be too disruptive to introduce in v8.1. But the glorious will be accompanied by the less wondrous--bugs, bumpy upgrades, and a very short support lifespan. Anyone who deploys 8.2 without Basic Care to tide you over until v8.3 (LTS again), or fails to upgrade v8.2 to v8.3 as soon as practical, is simply playing with fire.
IA could emphasize this more when in the middle of a non-LTS release, but that is hard to do amidst the marketing hype and new feature excitement. A buzz-kill indeed.