Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Feature]: should you Keep a Changelog?

Abierto
  • ¿Algo no está bien?
#18 1 comentario 2 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Área
documentation, release

Línea de trabajo

Empieza revisando la estructura propuesta de CHANGELOG.md y la guía de Keep a Changelog enlazada en la issue. Aclara si el cambio inicial solo incluye el archivo de changelog o también la automatización de slash-command sugerida; se considera terminado cuando el enfoque de changelog acordado está documentado en el repositorio.

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

Descripción

enhancement

Problem Statement

Keeping a changelog seems reasonable.

Proposed Solution

Add a CHANGELOG.md.

https://keepachangelog.com/en/1.1.0/

Alternatives Considered

Use pure GitHub releases, no changelog as file.

Use Case

Describe the use case(s) this feature would enable:

  1. Getting to know the capabilites of the plugin. Changelog helps.
  2. Wanting to know if a recent change is maybe the cause of trouble people have.

Additional Context

I tried automating it with a slash command and the outcome is not the worst.

---
description: Analyzes recent git commits, determines version bump, and updates CHANGELOG.md following Keep a Changelog and Semantic Versioning guidelines.
subtask: true
---

Follow these steps to update the CHANGELOG.md file based on recent changes in the git history.

First, review the key guidelines from Keep a Changelog (https://keepachangelog.com/en/1.1.0/):

- Use CHANGELOG.md as the file name.
- Follow reverse chronological order with the latest version first.
- Each version entry: [version] followed by ISO 8601 date (YYYY-MM-DD).
- Include an [Unreleased] section at the top for upcoming changes.
- Sections: Added (new features), Changed (existing functionality), Deprecated, Removed, Fixed (bugs), Security (vulnerabilities).
- Best practices: Adhere to Semantic Versioning; keep human-readable; include release dates; make linkable; avoid empty sections; mark yanked releases.

Next, review Semantic Versioning 2.0.0 (https://semver.org/spec/v2.0.0.html):

- Version format: MAJOR.MINOR.PATCH (e.g., 1.2.3).
- Pre-release: Append -alpha.1 etc.; build metadata: +001 (ignored in precedence).
- Increment: MAJOR for incompatible API changes; MINOR for backward-compatible additions/deprecations; PATCH for backward-compatible bug fixes.
- Version 0.y.z for unstable initial development.
- Precedence: Compare MAJOR/MINOR/PATCH numerically; pre-releases lower than normal; compare pre-release identifiers lexically/numerically.

Now, analyze the project:

1. Get the current CHANGELOG.md content: @CHANGELOG.md

2. Identify the last released version from CHANGELOG.md or git tags: !git describe --tags --abbrev=0 || echo "0.0.0"

Let last_version = output of above.

3. Get commit messages since last version: !git log --pretty=format:"%s" ${last_version}..HEAD

If no commits, respond: "No changes since last version. No update needed."

4. Classify each commit message into categories (Added, Changed, Deprecated, Removed, Fixed, Security). Use conventional commit prefixes if present (feat: → Added, fix: → Fixed, breaking: → Changed with MAJOR bump).

5. Determine version bump:
   - MAJOR if any breaking changes.
   - MINOR if new features (Added) but no breaking.
   - PATCH if only fixes/changes without new features or breaking.
   - If pre-release needed, append -alpha.1 etc. (decide based on stability).

Compute next_version by incrementing from last_version accordingly.

6. Group changes under appropriate headings. Omit empty sections.

7. Get today's date: !date +%Y-%m-%d

8. Decide on release strategy:
   - For unreleased changes: Add or update the [Unreleased] section at the top.
   - For a new release: Create new section ## [next_version] - today's_date

Add the grouped changes to the appropriate section.

If [Unreleased] exists, incorporate or replace it.

9. Preserve existing CHANGELOG content, inserting the new section after the header or updating [Unreleased] as appropriate.

10. Output the full updated CHANGELOG.md content.

If $ARGUMENTS provided, use it as additional changes or override (e.g., /update-changelog "Added: new feature").

Ensure the update is accurate, concise, and follows the guidelines exactly.
Lenguaje dominante
TypeScript
Estrellas
601
Forks
66
Merge medio
4 d 9 h
PR fusionados (30 d)
1

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 shekohex/opencode-pty

Todos los issues de shekohex/opencode-pty

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.