Details
- Reviewers
gjb wblock - Group Reviewers
doceng secteam - Commits
- rD51261: Update website to make 11.0 unsupported now that it is EoL.
Diff Detail
- Repository
- rD FreeBSD doc repository - subversion
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 13390 Build 13622: arc lint + arc unit
Event Timeline
shouldn't we try to renumber the rel0.current/rel1.current stuff ? I forgot how we did that in the past though so I can be mistaken :)
Cheers
Remko
Generally, yes, but it tends to be a bit more complicated than what Gordon has proposed here.
Also, we are likely going to have multiple from the same branch supported like we did with 11.0/11.1.
Alternatively, I can just say we switched from a 0-based counting system to a 1-based counting system.
It also may make things easier to update when the next major version is available, i.e., 12.0-RELEASE.
We really need a better way to handle this. Perhaps a list of entities for supported releases, then during a build, concatenate them into an entity that can be used directly in the DocBook source. Then we can get away from this FIFO, or, more accurately, "it is really hard to change these" changes.
Example:
SUPPORTED_RELEASES="11.1 10.4 9.3"
generates an entity called supported.releases containing 11.1, 10.4, and 9.3. If it was just the first two, it would be 11.1 and 10.4.
Maybe we could just generate a complete usable sentence: &supported.releases.sentence; expands to Currently supported versions of &os; are 11.1, 10.4, and 9.3..
This assumes we need to have a list of separate entities for each version. Otherwise, we could just create the entity statically.