Skip to content

Maintenance

Joseph Cayouette edited this page Dec 4, 2019 · 1 revision

Maintenance

Don't neglect your final project tasks, even if they are not your favorite part of a project.
The project will suffer permanent damage if you do not ensure that records are organized and material archived

Summary of changes

Content Cleanup

All books have been reworked into a new structure:

Old Naming Format:

  • Getting Started

  • Best Practices

  • Reference

  • Advanced Topics

New Naming Format:

  • Installation Guide (Requirements, supported platforms, installation methods, etc)

  • Client Configuration Guide (Configuring and connecting clients to {productname})

  • Upgrade Guide (Migrate and update clients and {productname})

  • Reference Manual (Comprehensive guide to the {webui})

  • Administration Guide (Maintenance and administration tasks in {susemgr})

  • Salt Guide (A comprehensive guide to Salt for system administrators)

  • Architecture (Details on components, salt/traditional architectures, and diagrams)

We have added a prototype of real time search using Algolia. We are still developing an alternative for offline reading.

Antora Static Site

All documentation is now written in AsciiDoc and built with Antora.

Documentation by Version

Select which version of the documentation you want to view, by using the version switcher at the bottom of the navigation pane.

User Contributions

Readers can now contribute directly to any document they are viewing.

PDF Output

Asciidoctor-pdf is currently used to produce PDF documents from our antora nav lists.

Faster Publishing

Our new documentation site implements continuous integration with TravisCI. As soon as as change is approved, TravisCI rebuilds the documentation and updates the published version within 3-5 minutes.

Reviewing the Documentation

Both the structure and the content of the documentation must continue to be maintained during its active life. The content, as with the product itself, will be constantly reviewed through the normal process of bugs and testing. The structure and toolchain, however, being a wholly new implementation, will require some additional effort:

  • Conduct customer (internal and external) reviews every 2-3 years (these should mimic those done in the planning stages, in order to provide a useful dataset that can be compared historically).

  • Conduct reviews of the information architecture every 3-5 years to ensure that the content structure hasn’t drifted too far from the original design (and correct it if required).

  • Monitor and adjust the performance of the site and toolchain on an ongoing basis.

End of Life

SUSE products are supported for up to thirteen years: ten years as general support, and a further three years with extended support. We can expect a y-release update to occur every 3-6 months.

Period Updates Required

2020-2024

New features, bug fixes, general maintenance

2025-2029

Bug fixes, general maintenance

2030-2031

General maintenance

2032

End of Life

At the time of end of life, the documentation must be archived, and removed from the site.

Clone this wiki locally