Skip to content

Install guide: use a tested release tag instead of dev #106

Open

Description

@fjlopez

Both install guides tell users to clone dev, which changes on every commit. A user who follows the guide can get a broken build, as happened on 2026-10-20.

This issue changes no code. Do it first. It does not need #107 or #108.

Where users are sent to dev

Location Text
https://sitmun.github.io/getting-started/instalacion/ (source: sitmun/sitmun.github.io docs/getting-started/instalacion.md) git clone --branch dev --recurse-submodules …
Stack README.md, Quick Start and Development Installation same command

On 2026-10-20 an outside user followed sitmun.org → Projecte → sitmun.github.io → Instalación. docker compose up -d built no containers, because #97 had just broken the front image (fixed by #99, prevented by #108).

Facts

  • main is the default branch and equals the sitmun-application-stack/1.2.9 tag (a2777001, 2026-09-20). Only --branch dev puts users on unreleased code.
  • sitmun-application-stack/1.2.9 has not been verified to start with docker compose up -d on a clean clone.
  • This repository has tags but no GitHub Releases (gh release list is empty). Release notes exist only in CHANGELOG.md.
  • The guide says ./setup.sh copies .env.example. That file was removed (CHANGELOG.md). setup.sh copies profiles/development-postgres.env when .env is missing.
  • 1.3.0, the first LTR (LTR 1.3.0 #104), is about to be released and is the natural tag to name.

Tasks

  • On a clean machine, clone the target tag (1.3.0 when cut, or 1.2.9 in the meantime) with --recurse-submodules, run ./setup.sh and docker compose up -d, and confirm admin and viewer load. Record the result on the release.
  • Publish a GitHub Release for that tag, with notes from its CHANGELOG.md section.
  • Change the end-user steps in both guides to git clone --branch sitmun-application-stack/X.Y.Z --recurse-submodules ….
  • Move --branch dev into a separate "Development" section that says dev can be broken.
  • Replace .env.example in the guide with profiles/development-postgres.env.
  • Add making a GitHub Release, and updating the tag in both guides, to RELEASE.md.

Acceptance

  • Following the public guide with no extra knowledge installs a tagged release that has been verified on a clean clone.
  • That tag has a GitHub Release with notes.

Related: #107, #108.

Activity

  1. added theissue type on Oct 22, 2026
  2. added
    plannedActive backlog; exempt from stale bot
    on Oct 22, 2026
  3. changed the title [-]Point the install guide at a tagged release instead of dev[/-] [+]Install guide: use a tested release tag instead of dev[/+] on Oct 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationplannedActive backlog; exempt from stale bot

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions