Page MenuHomeFreeBSD

Documentation EoL for 11.0-RELEASE.
ClosedPublic

Authored by gordon on Dec 6 2017, 5:46 AM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 23 2024, 5:09 AM
Unknown Object (File)
Dec 26 2023, 8:18 PM
Unknown Object (File)
Dec 22 2023, 11:04 PM
Unknown Object (File)
Nov 11 2023, 2:59 AM
Unknown Object (File)
Nov 7 2023, 11:58 AM
Unknown Object (File)
Nov 4 2023, 2:14 AM
Unknown Object (File)
Oct 24 2023, 9:26 PM
Unknown Object (File)
Oct 10 2023, 2:00 AM

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

I should have added secteam as well. Sorry about that.

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

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 :)

Generally, yes, but it tends to be a bit more complicated than what Gordon has proposed here.

This revision is now accepted and ready to land.Dec 6 2017, 7:15 PM
In D13392#279901, @gjb wrote:

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 :)

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.

In D13392#279901, @gjb wrote:

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 :)

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.

This revision was automatically updated to reflect the committed changes.

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.