The direction of #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) appears to be leaning towards the requirement of supporting multiple git repositories per project. This is described as option "3b":

3) MAJOR.MINOR.PATCH with variants/editions
We adopt the semver-assumed situation where a repository does indeed only contain a single history. A project evolves through a regular version history and updates its core dependency as needed. If the need arises to backport the latest major version to a previous core version, a new git repository is created for the [b]ackport to live in.[...]:
[...]
b) Drupal.org is extended to support multiple repositories per project. Any repositories beyond the first/default again are named based on some naming convention.

Some of the goals that appear to have been agreed upon include actually using Semantic Versioning, as opposed to a Drupalism, and keeping a single, canonical page per project.

A sticking point appears to be the amount of effort required to accomplish this option. Let's discuss that here, and see how realistic it is to do in a reasonable time-frame.

Note that this is essentially the reverse of #1005572: Support projects in shared repos.

Comments

ergonlogic created an issue.

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

Just scrawling some notes here:

  • UI/UX changes - supporting multiple repos from project page - how is that displayed?
  • Documentation changes - Need to update everything that mentions how things work now to how they would work
  • Migration of data - lots of git filter branches and making new repos. What happens to existing clones of combined repos?
  • Authentication questions - need to sort out the access control - Am I a maintainer of a whole project? or just a particular major version of a project?
  • Project module updates for version changes
  • Testbot changes to support
  • packaging script changes
  • updates process changes
  • download counts and usage counts
  • cgit links
webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Why is this option even on the table? Nowhere else in all of the various other projects that employ a plugin architecture do you have to traipse around looking at multiple git repos to find the code. It's always in one code base, with multiple branches.

eelkeblok’s picture

eelkeblok
he/him
Primary language Dutch
Location Netherlands 🇳🇱
commented

Do you have examples? My gut feeling tells me that these projects do not have the need to support multiple flavours of the same project at any one time (beyond "Version 1.x.y is for Core Project 2.x - 4.x and version 2.x.y is for Core Project version 5.x and up - i.e. no intention of backporting the improvements in 2.x.y of the plugin to Core Project versions 4.x and lower).

But maybe we should discuss the merits of the various options in #1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc) and only discuss the technicalities of this particular proposal here. I think this issue is about exploring how realistic this option is, should we decide we actually want this.

eelkeblok’s picture

eelkeblok
he/him
Primary language Dutch
Location Netherlands 🇳🇱
commented

One other tidbit of input. While reading through #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces, I came across the mention of Git namespaces, which I was not familiar with yet. That might be another way to get each module flavour their own endpoint (including tag space) for composer and the like, without the need to physically split Git repositories. Sounds almost like a best-of-both-worlds type deal.

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

GIt namespaces *would* allow you to have both d7 and d8 versions in the same repository, however, that would only go so far as to matter on the server side. Client side it would be essentially the same thing as having two repositories, so you would still "have to traipse around looking at multiple git repos "

I do believe, however, that we can avoid splitting the repos by only insisting on pure semantic versioning for those machine readable places that need them (specifically in composer.json) and that everywhere else we need to express a version, (git tags, project pages, info files, tarball names etc) we go ahead and stick with 8.x-1.0.0 methodology until such time as machines can accept that format as well.