Skip to content

Improve the way beta builds are marked #275

@ghost

Description

@taroth21 / @fsundermeyer / @tomschr -- I'd be happy about some feedback on this, because I am not sure in what way this issue should best be attacked.

  • Previous solution: just run DAPS with --draft
    • Looks a bit unprofessional, because --draft also turns on file metadata blocks and remarks
  • Current solution: run DAPS normally (Adding DRAFT status to DC files SUSE/doc-modular#37)
    • No difference to final version.
  • Solution for susedoc.github.io:
    • Run DAPS normally but hack a clickable banner into each document
    • The idea is not so bad (I think) but the implementation is extremely ugly, let's not do it like that for the proper site.

Things I can imagine:

  1. --beta parameter in DAPS or just a regular XSLT parameter like $beta-content=1

    • Could trigger adding the aforementioned banners via the stylesheets
    • Not sure where to source content for the banners from -- ideally, the content should be translatable and also depend on the product.
  2. Profile for PROFCOND=beta in DC files

    • Would trigger whatever is defined in the XML sources. (For example, a different &productnumber;, e.g. 1.0 beta instead of 1.0)
    • This approach is already used for the release notes, where it triggers display of an additional paragraph in the abstract (not super-effective, no).
  3. Some kind of special markup like <dm:betatext>This is beta software. It gives you special powers.</dm:betatext>

    • This could be combined with the triggers from (1)
    • Would be displayed at the top of each page or as a banner or something.

What do you say?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions