Maven Package Names with Colons Break --package Flag Parsing

[matthiassb]

The bug

The --package flag cannot handle Maven package names that contain colons (e.g., com.example:my-package) when creating releases. The current parsing logic splits on all colons, causing Maven packages like com.example:my-package:1.0.0 to be incorrectly parsed as having 3 components (com.example, my-package, 1.0.0) instead of the expected 2 components (com.example:my-package, 1.0.0).
This breaks the package override functionality for Maven repositories and other package types that use colons in their package identifiers.

Command to reproduce

octopus release create --project "MyProject" --package "com.example:my-package:1.0.0"

Outcome

The command fails to parse the package override string correctly, treating com.example:my-package:1.0.0 as a 3-component string instead of a 2-component package:version format. This results in an error during package override parsing.

Expected behavior: The Maven package com.example:my-package should be recognized as a single package identifier, with 1.0.0 as the version.

Actual behavior: The colon in the Maven package name is treated as a delimiter, breaking the parsing logic and causing the command to fail or incorrectly resolve package versions.

Potential Root Cause

The issue appears to be in the splitPackageOverrideString function in pkg/packages/packages.go (lines 223-225):

func splitPackageOverrideString(s string) []string {
    return util.SplitString(s, []int32{':', '/', '='})
}

This function splits on all colons without considering that package names themselves may contain colons, which is common in Maven's groupId:artifactId naming convention.
The package override format expects:

• 2 components: {package}:{version} or {step}:{version}
• 3 components: {step}:{package}:{version} or {package-ref}:{package}:{version}
  But Maven packages like com.example:my-package:1.0.0 get split into 3 components when they should be treated as 2.

Versions

cli: 2.18.0