Rethink the "upgrade required" banner when LTS

[marcbria]

As you all know, the LTS versions where created for those journals that like to follow a more conservative upgrade approach.
Anyway, never mind the path you select, if you are not in the last stable version, OJS will show you a banner like this asking to upgrade:

I think we are giving wrong messages here: Been outdated is a security issue that need to be addressed ASAP and it's ok to warn, but you can keep your system updated in the LTS path (that won't be the latest version) and the message will generate doubts.
I mean, existing banner will make Editors think their OJS is outdated when they are just in a more conservative upgrade path.

The easiest solution for this could be adding a different banner explaining they are safe but not in the latest stable when we detect they are in a LTS version. At same time, a different message could be included for outdated LTS versions asking to upgrade to the last LTS.

The "LTS - you are safe" message could be something like this (I'm sure you will rephrase it better than me):

Your current version is an updated LTS (Long Term Support) version, so you are safe and do not need to do anything.
Anyway, if you want to get new features, check with your technical support to upgrade to version 3.3.0-4.

The "LTS - need to upgrade to latest-LTS" message could be something like:

Your current version is an LTS (Long Term Support) version which is not up to date and should be upgraded to the latest LTS version (3.3.0-16).
Alternatively, if you want to get new features, check with your technical support to upgrade to version 3.3.0-4.

What do you think?

[alexxxmendonca]

Good point, @marcbria

I can definitely see this being a source of confusion for less technical people. I support having a different message tailored for those using an LTS version.

[marcbria]

I missed saying that I open this discussion because I think this warning is valuable, and we just need a better way to communicate it.
If somebody just want to avoid warning Editors about the required upgrades, OJS let you disable this notifications setting "show_upgrade_warning" variable in your config.inc.php:

; Display a message on the site admin and journal manager user home pages if there is an upgrade available
show_upgrade_warning = Off

[jonasraoni]

If the LTS is going to stay (i.e. regarding the maintenance burden of keeping 3 branches on GitHub for each application and their plugins), it definitely makes sense.

---

The latest version is retrieved from this URL: https://pkp.sfu.ca/ojs/xml/ojs-version.xml, there are some alternatives:

• Create a new file (ojs-lts-version.xml) or perhaps a new URL/format https://pkp.sfu.ca/ojs/version.json
• Extend the current XML file with a <lts> tag (it will break the .dtd validation for older releases, but it's probably not validated anyway)
• Follow the plugin gallery approach, I mean a file with versions and a compatibility table... If we're going to proceed with the approach of discarding upgrade/migration code for older versions (e.g. it's not possible to migrate from OJS 2 directly to OJS 3.4), then we could show the user the next version that he can use (or a migration path, upgrade to X > then Y, then Z). Personally, I'd like to keep the old migrations, but it has a cost...

Depending on the approach that we take, some updates will have to be done at the Beacon.

At the application side, I think it's enough to add a LTS flag to the LTS branches.

[marcbria]

Kind of OT but... what do you mean by "If the LTS is going to stay"?

The idea for the LTS came from within the Techcommittee when we noted that there are many people in the community who do not have the resources to keep up with OJS releases (and this results in many OJS being out of date). Alec and Nate proposed LTS to have longer cycles with security upgrades without "breaking changes".

Are we rethinking this decision?

It's only that I'm curious because it's a relevant change for anybody that maintain OJS but I don't want the conversation to get scattered. ;-)

[jonasraoni]

Don't worry. I'm not in the tech committee, so that was just my doubt as a developer :)

[marcbria]

Don't need to be in the tech committee to express legitimate doubts... and your opinion as a developer is extremely valuable.

I mean, from the TC we usually express needs/ideas/issues we think are relevant for the users/community side and as a technicians we can anticipate and understand dev team concerns... but we don't see the full picture of some of the proposals we make as, for instance, the real impact in dev work (only Alec does). :-)

So, if you think LTS is a bad idea, anytime is a good time to explain it.

[jonasraoni]

tl;dr: I think it's the right option for PKP, but the maintenance burden is real.

I think it's the best approach when you want to give users time to get used to the new things and prepare their upgrades slowly (e.g. custom plugins/themes/workflow).

The other, which is adopted by browsers, seems to be better when you have a ready product, and you don't mind much about the external environment, perhaps because the integrations are stable enough.

[marcbria]

It is as you say, but there are other factors as well.

The LTS is a child of the "great migration" (to give it an epic name)... a few years in which most OJS were on version 2.x and jumped to 3.1 which was already very stable.

The underlying issue was always that the upgrade from 2.x to 3.x included too much diversity in the source and target versions and major changes at many levels... so when attempting the jump, things broke in the worst way.

The LTS was born to ensure that there are no "breaking changes" and at the same time, to have a common starting point and destination, which will (hopefully) make the testing matrix smaller.