Problem
The Java ecosystem (Maven, Gradle) uses a versioning convention that differs fundamentally from .NET/NuGet in how it
handles pre-release and development builds. Currently, there is no way to produce Java-idiomatic version strings from
nbgv get-version without external post-processing.
The central challenge is that Java has a concept of SNAPSHOT releases which are meant to represent "non-release" builds and are NOT immutable. This is somewhat similar to .net/nuget support for wildcards. For example consumers can peg to 1.2.0-SNAPSHOT and developers may publish many builds that "update" what the snapshot points to. This would be quite similar to adding a "1.2.*" nuget dependency in your csproj. Without getting into discussions if this is a good idea, this is a common pattern in that ecosystem.
Additionally there's a versioning plugin for Java build system originally created by gradle called Nubula. It provides some additional opinions. While it tries to accomplish similar goals to nbgv it differs in many areas as it relies on tags for version computation. The logic is also centralized as java build plugin which makes it very awkward to consume when trying to apply same versioning scheme to projects using multiple technologies.
Proposal
Extend the model to include additional fields to support easy consumption of this pattern such as following:
When on public branches:
JavaSnapshotVersion - {major}.{minor}.0-SNAPSHOT
When on non public branches
JavaSnapshotVersion - {major}.{minor}.0-{branch-name}-SNAPSHOT
Problem
The Java ecosystem (Maven, Gradle) uses a versioning convention that differs fundamentally from .NET/NuGet in how it
handles pre-release and development builds. Currently, there is no way to produce Java-idiomatic version strings from
nbgv get-version without external post-processing.
The central challenge is that Java has a concept of SNAPSHOT releases which are meant to represent "non-release" builds and are NOT immutable. This is somewhat similar to .net/nuget support for wildcards. For example consumers can peg to 1.2.0-SNAPSHOT and developers may publish many builds that "update" what the snapshot points to. This would be quite similar to adding a "1.2.*" nuget dependency in your csproj. Without getting into discussions if this is a good idea, this is a common pattern in that ecosystem.
Additionally there's a versioning plugin for Java build system originally created by gradle called Nubula. It provides some additional opinions. While it tries to accomplish similar goals to nbgv it differs in many areas as it relies on tags for version computation. The logic is also centralized as java build plugin which makes it very awkward to consume when trying to apply same versioning scheme to projects using multiple technologies.
Proposal
Extend the model to include additional fields to support easy consumption of this pattern such as following:
When on public branches:
JavaSnapshotVersion-{major}.{minor}.0-SNAPSHOTWhen on non public branches
JavaSnapshotVersion-{major}.{minor}.0-{branch-name}-SNAPSHOT