GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Support individual component version release · Issue #281 · scijava/scijava

Support individual component version release #281

New issue
Copy link
New issue
Copy link
Open
Open
Support individual component version release#281
Copy link
Labels
enhancementquestion
Milestone
1.0.1

Description

@hinerm
hinerm
opened on Jan 16, 2025
Issue body actions

This repository is structured as a multi-module Maven project except that each "module" is treated as distinct and inherits from pom-scijava instead of a single reactor pom.xml in the project.

For the initial release of SciJava Ops we were able to get away with keeping all intra-repo dependencies at project.version because each project was at the same 1.0.0 version. However, this left us with technical debt for releasing future individual components. We do not want to bump all component versions each time a single component needs release, as this creates a large amount of vacuous releases that are likely meaningless and violate (or at least mislead) SemVer.

First requirement, as standalone projects:

  • All individual projects should have entries in the dependencyManagement section of the pom-scijava bill of materials, with appropriately named component.version properties defined.

Problem 1:
Unfortunately, although these projects should be managed in pom-scijava, these are all release versions. Within the reactor we still want SNAPSHOT versions for these dependencies so that changes in one are immediately reflected in another, thus we can't actually use the component.version properties inherited from pom-scijava.
Discussion point: is this a technical requirement or one of convenience? If we keep everything release-coupled, the development process would be no different than if the projects were in separate repositories (e.g. manually pinning to SNAPSHOTs or "fake" versions for local testing) and we wouldn't have to worry about the enforcer, right?

Problem 2:
The maven-release plugin, and our release-version.sh script, don't support releasing individual components out of a multi-module reactor. Therefore we currently have no way to actually perform component releases reliably.

Second requirement:

  • Create a new release script, for a single component in a multi-module reactor:
    • Manually performs any required maven-release steps
    • Creates a component-name-component-version tag with the release commit
    • Updates version properties in other components?'
    • ... what else?

Activity

  1. hinerm
    added
    enhancement
    question
    on Jan 16, 2025
  2. hinerm
    added this to the 1.0.1 milestone on Jan 16, 2025
  3. gselzer commented on Jan 16, 2025

    @gselzer
    gselzer
    on Jan 16, 2025
    Member
    More actions
    • All individual projects should have entries in the dependencyManagement section of the pom-scijava bill of materials, with appropriately named component.version properties defined.

    I added these with scijava/pom-scijava#282, however the build fails due to the projects being built on Java 11 ☹

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

    enhancementquestion

    Type

    No type

    Projects

    No projects

      Milestone

      • 1.0.1No due date

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.