0.8.1: readable release notes in System (Update section, rendering, notes rules as a check)

Abierto
#507 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python, rust

Línea de trabajo

Start with capsules/system/browser/system.js to trace how the About section renders the update offer, then inspect scripts/release-platform-input-test.py and its existing size test. The work also requires moving the offer into an Update section and adding checks for the listed release-note rules. Done means the Update section renders readable notes and the checks reject violations, including a release heading with an allowed date.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Found 29 Oct while preparing 0.8.0. Anders: notes stay as they are for 0.8.0; this is 0.8.1 work.

1. System > About shows release notes as raw text. The update offer is drawn by the installed System (capsules/system/browser/system.js, the update-changes field): bullets become plain lines joined by newlines in a pre-wrap paragraph, the Security/Added/Changed/Fixed headings are lost, and Markdown (backticks, bold) shows as raw characters. Because the installed System draws the offer, a fix reaches users with the update after the one that ships it.

2. Update as its own section in System. Move the update offer, its notes and the update action out of About into an Update section.

3. Release-notes rules as a check, not a guide. Add these to scripts/release-platform-input-test.py next to the existing size test, so the notes test fails instead of relying on a reviewer:

    1. Size: at most 32 bullets, each at most 500 UTF-8 bytes, at most 8192 bytes in total (continuation lines joined).
    1. Plain text only: no backtick, "**", "text", HTML tag, arrow (U+2192), em dash (U+2014), en dash (U+2013), " -- " or curly quote (U+2018, U+2019, U+201C, U+201D); menu paths use " > ".
    1. Banned words, case-insensitive whole words: now, seamless, seamlessly, easily, simply, robust, additionally, crucial, enhance, leverage, ensure, ensures.
    1. Banned internal terms: capsule, gateway, principal, sidecar, endpoint, Origin header, TLS, .rs, .py, .js, Cargo.
    1. An issue reference (#N) appears only in a bullet that states a limit: the bullet contains "Known issue", "not", "cannot", "can't" or "still".
    1. Each bullet stands alone on one line, because System shows bullets without their heading: it starts with a capital letter and ends with ".".
    1. The section heading reads "## [X.Y.Z] - YYYY-MM-DD" and its date is not earlier than any older section's date.

A humanized rewrite of the 0.8.0 notes that passes these rules and the size test was drafted (32 bullets, 8177 B, plain text); use it as the model for 0.8.1's notes.

Lenguaje dominante
Rust
Estrellas
6
Forks
2
Merge medio
1 d 3 h
PR fusionados (30 d)
42

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de elastos/elastos-runtime

Todos los issues de elastos/elastos-runtime

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.