Better way to control/sync versions

kaspersorensen commented 8 years ago

Right now the pom.xml version gets inserted as a "suffix" instead of the * symbol in project.json.

Ideally the pom.xml version should somehow dictate the version that gets published by dotnet/nuget/project.json.

kaspersorensen commented 8 years ago

Reported to the maven release plugin project, here: https://issues.apache.org/jira/browse/MRELEASE-962

kaspersorensen commented 7 years ago

Looking at the new .csproj format, it seems that the <ProjectReference> element almost elminates this issue.

FlorianHockmann commented 7 years ago

Could you please clarify this a bit? I'm also interested in controlling the version of the resulting NuGet package from the pom.xml, but I don't see how this could be accomplished right now.

kaspersorensen commented 7 years ago

Well the main issue here was that if your solution had multiple projects in it, and you wanted to keep the project versions in sync. With project.json you would reference other projects just like any other dependency, so including version and all. But with .csproj files you would rather make a <ProjectReference> and make it point at the path of that other project. That way you wouldn't have to keep versions in sync, because there is no longer a dependency version in the build file.

FlorianHockmann commented 7 years ago

So you're talking about not having to update the versions of your own projects that include each other?

Does propagating the version from the pom.xml during a Maven build / release (whatever) to the .csproj files for the versions of the projects themselves currently work? I noticed that you implemented something that seems to be targeting this, but I couldn't get it to work and I didn't find an example of that.

kaspersorensen commented 7 years ago

Ah right, it's actually not in the examples. We should create an example. But here's a quick snippet for ya:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <configuration>
        <preparationGoals>dotnet:update-versions scm:checkin -DpushChanges=false -Dincludes="**\project.json" -Dmessage="prepare project.json for release"</preparationGoals>
        <completionGoals>dotnet:update-versions scm:checkin -DpushChanges=false -Dincludes="**\project.json" -Dmessage="prepare project.json for next development iteration"</completionGoals>
    </configuration>
</plugin>

A few notes on this snippet:

This somewhat ackward way of doing it is currently needed because there are no hooks (to my knowledge) to automatically make it part of the release plugin (see https://issues.apache.org/jira/browse/MRELEASE-962)
It assumes you're using project.json files. If not, you should modify the -Dincludes part.
You may want to further specify release plugin version, and I also usually have to specify the git scm provider. But that technically has nothing to do with the dotnet plugin configuration. Anyway, here's a full example from one of my projects:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.5.3</version><!--$NO-MVN-MAN-VER$ -->
    <configuration>
        <autoVersionSubmodules>true</autoVersionSubmodules>
        <preparationGoals>dotnet:update-versions scm:checkin -DpushChanges=false -Dincludes="**\project.json" -Dmessage="prepare project.json for release"</preparationGoals>
        <completionGoals>dotnet:update-versions scm:checkin -DpushChanges=false -Dincludes="**\project.json" -Dmessage="prepare project.json for next development iteration"</completionGoals>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.apache.maven.scm</groupId>
            <artifactId>maven-scm-provider-gitexe</artifactId>
            <version>1.9.5</version>
        </dependency>
    </dependencies>
</plugin>

t9t commented 6 years ago

@kaspersorensen I'm not sure if this issue is about versioning of the dotnet application or something different, but I've noticed the following.

If I use <Version>$(VersionSuffix)</Version> as version in my .csproj, and then run dotnet build --version-suffix=1.2-alpha, it will use "1.2-alpha" as the full version of the build. So if the Maven project version could be specified in --version-suffix (maybe controlled with a configuration property, something like <enableVersionSuffix>, of even better a free-form <versionSuffix> which defaults to ${project.version}), then that would solve the consistent Maven/dotnet versioning at least for .csproj projects.

Unfortunately I have no experience with project.json projects, so I don't know if this could be applied for those.

Edit: I wrote before that I didn't use any version in my .csproj, but that's false. I did set it to $(VersionSuffix). When not specifying a version, it becomes 1.0.0-1.2-alpha using above example.

For now, I've worked around it by using an environment variable MAVEN_PROJECT_VERSION. In my .csproj I have:

<PropertyGroup>
  <Version>$(MAVEN_PROJECT_VERSION)</Version>
</PropertyGroup>

And then in my Maven pom.xml in the plugin's <configuration>:

<environment>
    <MAVEN_PROJECT_VERSION>${project.version}</MAVEN_PROJECT_VERSION>
</environment>

kaspersorensen commented 6 years ago

I like both approaches. And as a plugin I think we should support all of the approaches, and have an example for them too.

kaspersorensen / dotnet-maven-plugin

Better way to control/sync versions #1