Confusion in branch naming for publishing my extension

Development
,
1

I want to publish my scripted extension to the extension manager but after going through different doc pages, I am still confused about branch names.

What I want to do: publish my extension on both stable version and preview version. My code is on master (not main) branch

What I know I should do: submit a json to main and an s4ext file to 5.6 branch

What I am not sure about:

  • should i submit separate pull requests for main and 5.6 branch separately?
  • what should i put in scmrevision field? main (as in the destination branch on your repo) or master (as source branch on my repo)

Thanks in advance!

2

Indeed, a pull request should be submitted against master to have the extension built for the Slicer Preview and against the latest X.Y branch to have the extension built for the latest stable release.

The scm_revision field should indeed be set to the revision (either a SHA or a branch name) associated with your extension repository.

For reference, see https://slicer.readthedocs.io/en/latest/developer_guide/extensions.html#extension-catalog-entry-file

1 Like
3

Branch name: you can use any branch name, but to be consistent with all new repositories (and an increasing number of existing repositories) and thereby avoid any complications, I would recommend using the current default: main. Using the old default - master - indicates that the project is unable or unwilling to follow current trends, which may slightly discourage some potential contributors and funding sources. Changing the branch name (e.g., pushing master branch content to main and change th3 default branch in github) takes a few minutes.

scm_revision: Using a git hash allows you to specify exactly what extension source code has to be used with what Slicer version, but you need to update this git hash in the extensions index each time you update your extension. Using a branch name makes it difficult to determine exactly what extension version was compatible with an older Slicer version; but it is more convenient, because you do not have to send a pull request to the extensions index after each extension change (the latest version is picked up automatically each night).

@jcfr Would you prefer extension developers to generate a pull request after each change? Most extension developers don’t do this and I would much prefer not to do this for the dozens of extensions that I maintain. I would be ready to switch to using git hash if a pull request was automatically generated by a single click or when a new github release is created for thr extension. However, until then I would not require developers to use git hash.

1 Like
4

Developers will not have to do this.

Instead, this will be automated like what is done with dependabot for “pinned dependencies”.

Since we can’t have comment in json file, I am thinking to introduce a new optional field called scm_revision_reference. This means that files like the following:

{
  "$schema": "https://raw.githubusercontent.com/Slicer/Slicer/main/Schemas/slicer-extension-catalog-entry-schema-v1.0.0.json#",
  "build_dependencies": [],
  "build_subdirectory": ".",
  "category": "Developer Tools",
  "scm_revision": "master",
  "scm_url": "https://github.com/Slicer/SlicerDeveloperToolsForExtensions.git"
}

will be automatically updated like this the first time:

{
  "$schema": "https://raw.githubusercontent.com/Slicer/Slicer/main/Schemas/slicer-extension-catalog-entry-schema-v1.1.0.json#",
  "build_dependencies": [],
  "build_subdirectory": ".",
  "category": "Developer Tools",
  "scm_revision": "cc2a33a2b27858bb9d9caa3d9027032322216a25",
  "scm_revision_reference": "master",
  "scm_url": "https://github.com/Slicer/SlicerDeveloperToolsForExtensions.git"
}

Then, on a daily basis, the “scm_revision_reference” will be automatically updates for all relevant extension files for which the upstream repository set in svm_url has been updated.

5

This would be nice. It would ensure that git hashes are archived without requireing extension developers to generate pull requests. Would dependabot update the files automatically or Slicer maintainers would need to merge each pull request?

6

Thank you for your response! As a follow up question, if I submit a PR for 5.6, will my plugin be automatically accessible through older versions like 5.4 too? Or will it only be visible to the latest stable version users?

7

The 5.6 branch will make it available for the latest Slicer stable (5.6.2). It will not be available in older stable release (5.6.1, 5.6.0, 5.4.0 and older). The Slicer factory build machine only builds new extension packages for the latest Slicer stable and latest Slicer preview.

1 Like