Change Details

Our deployment kit major versions are tied to mediawiki versions. mediawiki has a fixed release and maintenance schedule. do we follow that schedule?

Core decision: how do we structure our commitment to support current and past versions of the Wikibase Suite [deployment kit]? Context: Our [deployment kit] major versions are incremented by mediawiki versions. This is what [[ https://www.mediawiki.org/wiki/Version_lifecycle | MediaWiki does ]]: - supports three versions: current, legacy and LTS versions - A major release will be made every six months. - A minor release (including security patches, message translation back-ports, and general bugfixes) will be made every quarter. - A long-term support release (LTS) will be made every two years. There will be a one-year overlap in LTS support. For example, 1.23 was supported until May 2017. 1.27 was released the year before, so that people have it available as an LTS to move to and a year to make the transition. This is what WMDE was doing when the Suite team came to be: (my best recollection, correct me pls) - last two versions - one year of support - no LTS commitment Questions for Engineers re cost of supporting older versions: 1. Does the cost increase roughly linearly? Or is there a big drop off between 2 vs. 3 versions being supported? 2. Is back-porting a relevant concern here? 3. What are the total number of releases we would theoretically support if we support 2 vs 3 versions. 4. is there a difference in committing to support security fixes vs backporting feature work? is there a benefit to us in doing that? 5. how do our service images fit into this context? same issue? do they all have LTS versions? do we also make similar commitments w/in those dependancies? Questions to UXR: - do we have any proof/indicators of need for LTS versions? (telegram discussions, old research, loomio) - do we have any data on current software version numbers of known instances?

Our deployment kit major versions are tied to mediawiki versions. Core decision: how do we structure our commitment to support current and past versions of the Wikibase Suite [deployment kit]? Context: Our [deployment kit] major versions are incremented by mediawiki versions. This is what [[ https://www.mediawiki.org/wiki/Version_lifecycle | MediaWiki does ]]: - supports three versions: current, legacy and LTS versions - A major release will be made every six months. - A minor release (including security patches, message translation back-ports, and general bugfixes) will be made every quarter. - A long-term support release (LTS) will be made every two years. There will be a one-year overlap in LTS support. For example, 1.23 was supported until May 2017. 1.27 was released the year before, so that people have it available as an LTS to move to and a year to make the transition. This is what WMDE was doing when the Suite team came to be: (my best recollection, correct me pls) - last two versions - one year of support - no LTS commitment Questions for Engineers re cost of supporting older versions: 1. Does the cost increase roughly linearly? Or is there a big drop off between 2 vs. 3 versions being supported? 2. Is back-porting a relevant concern here? 3. What are the total number of releases we would theoretically support if we support 2 vs 3 versions. 4. is there a difference in committing to support security fixes vs backporting feature work? is there a benefit to us in doing that? 5. how do our service images fit into this context? same issue? do they all have LTS versions? do we also make similar commitments w/in those dependancies? Questions to UXR: - do we have any proof/indicators of need for LTS versions? (telegram discussions, mediawiki has a fixed release and maintenance schedule.old research, loomio) - do we follow that schedulee have any data on current software version numbers of known instances?