Contrib.social

Workflow for working with true semver is tedious

Open on Drupal.org →
Created on 25 August 2023, 10 months ago
Updated 28 August 2023, 10 months ago

Problem/Motivation

In true semantic versioning, you increment the minor version number whenever you introduce new features. So 1.0.0 can go all the way up to 1.0.123821371238 as long as these were bugfix releases, but once there are new features, you should release 1.1.0. The current drupal.org infrastructure makes this really cumbersome to pull off.

Currently you have to:

  1. Create a new dev release for the new minor version
  2. Create a tagged release for the new minor version
  3. Remove the tests from the previous minor version
  4. Add the tests to the new minor version
  5. Change the releases to now support the new minor version and remove the previous one

Every time you want to release a new feature.

If you don't unsupport your previous minor versions, the module page becomes unwieldy to navigate releases on.

Proposed resolution

TBD, we could perhaps let some aspects of the site work off of major branches, but ideally this needs a more thorough discussion than a simple solution thought up by one person when writing the issue summary.

✨ Feature request
Status

Active

Version

2.0

Component

Projects

Created by

🇧🇪Belgium kristiaanvandeneynde Antwerp, Belgium

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @kristiaanvandeneynde
  • Comment 10 months ago →
    🇧🇪Belgium kristiaanvandeneynde Antwerp, Belgium

    Relating an issue that also suffers from the granularity of showing minor vs major version.

  • Comment 10 months ago →
    🇺🇸United States drumm NY, US

    Branches with dev releases can’t be force pushed to. Creating the release allows the maintainer one last chance to spot any issues before the commits are effectively permanent. If dev releases were made automatically, that protection would catch a few maintainers off-guard. That said, dev releases do get forgotten. This is even more true for tagged releases.

    With GitLab CI, testing configuration moves to a .gitlab-ci.yml file in the repository, and will follow branching around automatically. See https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

    “Recommended” release series is a bit of a Drupalism, I'm not aware of other projects using that on top of “use the latest stable release.” I believe the only thing it does nowadays is change the color of some of the boxes on the project page. It does not appear in Composer metadata or the current version of the update status XML. We could remove it someday.

    Automatically marking new release series as supported would be a good idea.

    At some point, Drupal.org will support using a main branch, 🌱 Use a 'main' branch as the development target Active

  • Comment 10 months ago →
    🇧🇪Belgium kristiaanvandeneynde Antwerp, Belgium

    Yeah I might have to look into that gitlab ci thingy sooner than I planned to.

    The main branch does sound like a good idea for most projects, but that still won't solve maintaining two major versions concurrently, right? Asking for a friend.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024