Estimated time to implement: not sure - at least a week, possibly longer
Motivation
Users who need to upgrade from, say, 2.5 to 2.7 currently need to read a separate Porting Guide for each "step" of the upgrade: the 2.6 porting guide to upgrade from 2.5 to 2.6, then the 2.7 porting guide to upgrade from 2.6 to 2.7.
If we could build an interface where customers could select their current version and their target version, then get a custom porting guide, preferably sorted by the functionality affected, this might make upgrades less daunting.
Problems
PRs with porting guide entries get frequent merge conflicts from the porting guide file
Solution proposal
TBD
Testing (optional)
Yes, probably.
Documentation (optional)
Would work best if we divided the current porting guides (at least for supported versions).
Also would need to document how to write porting guide fragments.
Proposal:
Author: Alicia Cozine <@acozine>
Date: 2018-11-30
Motivation
Users who need to upgrade from, say, 2.5 to 2.7 currently need to read a separate Porting Guide for each "step" of the upgrade: the 2.6 porting guide to upgrade from 2.5 to 2.6, then the 2.7 porting guide to upgrade from 2.6 to 2.7.
If we could build an interface where customers could select their current version and their target version, then get a custom porting guide, preferably sorted by the functionality affected, this might make upgrades less daunting.
Problems
Solution proposal
Testing (optional)
Yes, probably.
Documentation (optional)
Would work best if we divided the current porting guides (at least for supported versions). Also would need to document how to write porting guide fragments.