LTS workflow proposal

From Koha Wiki
Jump to navigation Jump to search

Possible future workflows

3 RMaints, LTS 3 years

upsides

  • LTS!

downsides

  • only one year of support on the recent versions (stable and oldstable)
    • it's ok if doing major updates every 6 months (from .12 of oldstable to .06 of stable)
    • if doing yearly updates, must update from .12 to .00 or .01 versions which might not be polished enough
      • and the dates will be constrained compared to now. Because we now have oldoldstable so one can pick whichever time on the year to upgrade, just wait between 0 and 6 months on oldoldstable before upgrading to choose any month in the cycle. This proposal is more restrictive on that.

3 RMaints, LTS 3 years, 1 yearly release

There can still be a 6 months cycle for roles.

upsides

  • LTS!
  • still possible to upgrade yearly without using to .00 or .01 versions which might not be polished enough
  • 2 years support for recent releases instead of current 1.5 (side effect of 1 yearly release)

downsides

  • max delay for new features: 1y instead of 6mo

3 RMaints, LTS 3 years + rolling

upsides

  • LTS!
  • rolling release [1] for those needing new features and big enhancements quick
  • .00 versions more stable than today and more fit for wide deployment. The rolling branch should allow to catch big regressions in main before the release because main doesn't have big changes at the end of the cycle.

downsides

  • can't do yearly upgrades at all. Either every month rolling, every six months or every 2 years from LTS to LTS

3 RMaints, LTS 3 years + rolling, 1 yearly release

There can still be a 6 months cycle for roles.

upsides

  • LTS!
  • rolling release [1] for those needing new features and big enhancements quick
  • .00 versions more stable than today and more fit for wide deployment. The rolling branch should allow to catch big regressions in main before the release because main doesn't have big changes at the end of the cycle.
  • yearly updates possible, TODO

downsides

  • more constrained by the 1 yearly release. If we settle on the XX.11, then those doing yearly major update will have to do them around December, January. If we settle on the XX.05, then those doing yearly major update will have to do them around June, July. Whereas today both periods work. Actually now we have oldoldstable so one can pick whichever time on the year to upgrade.

[1] about the rolling channel

By default it would be monthly rolling releases from main. So bleeding edge, expecting a some more issues as with using the current XX.XX.00 versions. If there are a few production users (in addition the part of the Finish public libraries already using a mainish version) we could already reap the benefits of getting more stable .00 versions.

An attempt to improve could be more TODO

A strong and reliable improvement to get out of the bleeding edge status would need a significant commitment from the maintainer to do regression testing. This would need a funded position And alternative in the future will be with the expansion of the UI tests.

quick notes and additional toughs after the meeting

rely on 3 RMaints in total

maybe 3y of support minimum (2y is too close to our current 1.5y support)

possible workflow: LTS, stable and Rolling

↑ stable might be supported one year if that can help. In that variation it would be one major release every year. Every 2y one of them will become LTS (so 3y of support) And a rolling cutting edge (bleeding edge?) every month.

↑ team cycle can still be 6mo

possible workflow: LTS, oldstable and stable

have proposals with and without a rolling version and highlight the pro and cons of rolling

does the userbase for LTS exist? It's for instances that don't do major updates every year of 1.5 years. But that still do minor updates. Looking at older releases like 19.11 and 20.05 we can see that there are much much more instances that aren't on the latest point release.

How would that work for instances that do upgrades every year? And for which a few months to iron out major bug are necessary. So not installing a .00 That work as the rolling release will find the major issues and same as we do today, big changes are not merged in main in late cycle. So .00 or 01 versions would be more suitable for production.

TODO ask rangi what their intentions were when opening the discussion about LTS (reread the email thread)

Retrieved from "https://wiki.koha-community.org/w/index.php?title=LTS_workflow_proposal&oldid=33847"