Breaking Fewer Things with Fewer Broken Things

Just in time to induce Holiday Panic...

This release breaks the alt-syntax which was previously supported for repository targeting.

The only way to define a repository for targeting now is by the repo ID. This solves issues folks were having with authn/z on repos, and makes Wagon extensions (S3 buckets as a repo) viable.

This will require some mirror / repository configuration either in your pom, or a profile in your settings.xmls (any of them will do). The documentation has been updated to properly reflect expected configurations.

Changes / Improvements of Note

• Now builds against Maven 3.6.0. Prior maven releases may have issues executing. Maven < 3.6 is untested.
• Pulled in #113 to fix #112.
• Reduced code burden in the plugin by leveraging more Maven provided utils for working with deployment / artifact repository objects, and cutting complexity.
• Wagon extensions now properly work with remote repositories. It's possible to use things like the S3StorageWagon for remote snapshot / stage / release repositories.

Maven 3.6.0 Compatibility

Release 2.2.0 is out, with fixes for #104, and some documentation updates.

Ongoing work toward future issues will be rolled up into the next release.

Thanks to those who patiently waited for this release, and for helping patch / resolve issues.

Security is a thing

Thanks to the community report in #101 this hotfix resolves the issue by bumping a few dependency versions.

When a positive is a negative

In cases where a + is not a legal character for version strings, this release lets you change the delimiter to something else.

This specifically came about as a consequence of trying to push docker images with mutable tags based off the project version -- where the tag format prohibits the use of +.

Two Point Oh Oh.

This release fixes a regression regarding how enforce versions treated non-released (other) branches introduced in 1.8.0. Even if you weren't trying to release your feature branches to the snapshots repo some assertions began to happen on feature and bugfix branches that were not originally part of this plugin.

This restores the original behavior against non-release creating branches, and adds the ability to automagically generate -snapshot artifacts for those branches, if you so choose.

Improve All The Things

A way overdue release with loads of improvements.

• update-stage-dependencies can be enabled / disabled at will.
• enforce-versions can now disallow SNAPSHOT (plugin) dependencies for releaseable branches.
• 'other' branch types are now treated as snapshot-type branches.
• 'unknown' branches allow building as usual -- handy for projects without blocks being built without a CI server.
• Via the deploySnapshotTypeBranches parameter, feature branches can also be deployed to the snapshot repository. When true, the enforce-versions mojo will also check that the POM version number contains the branch name -- to prevent overwriting snapshots from develop.
• Fixes for NPEs when optional blocks were missing from the repository configuration.

SCM interaction Bug Fixes

Resolves a couple of bugs around SCM interaction.

• If a parent POM is defining an <scm> block without either a <developerConnection> or <connection> (common in spring boot apps), and the child project didn't define a connection URL, the result was a null pointer exception (Issue #74)
• Community contribution to improve tagging feedback. #72, fixed by #73! Thanks, Hans-Peter Schmid!

Support Branch Promote Extension

The 1.7.0 release introduced support for support branches, but the promote extension didn't modify the build process. Somehow I missed that in testing.

Repository fun-time!

This release does a few things with repositories and how we handle local & remote repos.

• I recommend setting up repository definitions for each remote repo gitflow uses (releases, test-releases, snapshots) in that order, followed by any other repositories your project uses. This is to enforce version resolution order when a stage dependency is purged. (look here, then here, then finally here)
• I recommend adding repository and mirror definitions to an active profile in your maven user settings.
• update-stage-dependencies is a new goal that can purge local repository release versions previously resolved from the 'stage' repository. This should resolve most of the issue documented in #50.
• Execution of plugins and goals which are not defined in the pom should no longer 'error'. #59
• Repository parameters no longer need to be in the id::foo::bar::blah format. You can reference a repository defined in the pom or in an active profile by id only. #64

As always, this release is Available in Maven Central

SCM All The things

1.6.0 - SCM All The Things

Rather than relying only upon environment variables injected by CI servers, we now leverage the SCM definition of the project wherever possible. This has had the following consequences:

• Branch patterns now include optional subgroup matching for the (origin/)? prefix.
• enforce-versions now expects the last subgroup from a match to equal the project version.
• The plugin can operate without environment variables being set, and will detect the current branch of the locally checked out git repo. In local environments, this even works as expected.
• To avoid the use of ${env.GIT_BRANCH} the plugin / extension will now use a developerConnection, connection, or ${env.GIT_BRANCH} (or the expression you provide) in that order, to resolve git branch, and to handle tagging.
• Since the plugin uses the SCMManager from maven now, the git command branch detection boils down the equivalent of this command: git symbolic-ref HEAD | sed 's/refs\/heads\///' being executed in the project base directory. Hence the optional sub-group match for (origin/)? now being part of the default patterns.
• The default development branch pattern has been changed to (origin/)?develop. If you were using the highly opinionated and verbose origin/development name, then you should specify this inside your plugin configuration.

Upgrading from 1.5.x

• Double check your developmentBranchPattern. You may need to specify one now (if you're using 'development' rather than 'develop')
• If you had to provide a custom gitBranchExpression, consider using the <scm> block of your project to define a <developerConnection>.
• If you have issues with git tagging, check your <scm> block to make sure you have the Git SCM URLs correctly formatted.