GitFlow: Include commits in PreReleaseTag for release, hotfix and feature branches

[yannisgu]

For release/hotfix branches currently the PreReleaseTag looks like this:

 -beta.1

and for feature-branches

  -feature-branch-name

The problem is that for every commit, the NuGet version will be the same. My proposition is to do the same as on the develop branch: Add the number of commits (build metadata) in the pre-release tag.

The change in the code will be trivial, but I want to hear your opinion, before I send a PR.

[gep13]

I would be happy to see this get added.

I have +1'd your suggestion with the ZenHub addin that we are now using on this repository:

[JakeGinnivan]

The problem is there are two styles of consuming builds, continuous deployment and continuous delivery.

Continuous deployment means you want each build to have a unique nuget version, continuous delivery means you do not.

When I am creating a release, I want to commit multiple times/submit multiple pull requests and when i am ready hit the deploy button which deploys the current version and then tags the vcs with that version.

Maybe we need to release v2, then level up the config in v2.1 and support something like:

mode: continuous-delivery

develop
   mode: continuous-deployment

release*
   mode: continuous-deployment
   tag: rc

This could actually simplify GitVersion by allowing us to simply support default conventions for different branch types via config and we can delete a heap of the hard-coded branch logic.

[yannisgu]

@JakeGinnivan I see the problem

Good idea! I think I will submit a work in progress PR to discuss about the implementation

[gep13]

When I am creating a release, I want to commit multiple times/submit multiple pull requests and when i am ready hit the deploy button which deploys the current version and then tags the vcs with that version.

There are a couple times when we have done this that we want to deploy (manually) a Pull Request build just to test out a few things before pulling into the develop branch. This works great the first time that you do this, but if you find that something is not quite right and go back and fix it, you can't then deploy the corrected pull request version, as the version already exists. In order to do it, we have to manually go and hack Octopus Deploy to delete the release, and associated nupkg packages, so that we can deploy again.

So it would definitely be nice if "something" can be done here to help with this edge case.

[robdmoore]

I thought that there was a version number that contained the commit count in the fourth build number that could be used specifically for generating nuget packages that increased in number every commit?

On 9 Dec 2014, at 9:56 pm, Jake Ginnivan notifications@github.com wrote:

The problem is there are two styles of consuming builds, continuous deployment and continuous delivery.

Continuous deployment means you want each build to have a unique nuget version, continuous delivery means you do not.

When I am creating a release, I want to commit multiple times/submit multiple pull requests and when i am ready hit the deploy button which deploys the current version and then tags the vcs with that version.

Maybe we need to release v2, then level up the config in v2.1 and support something like:

mode: continuous-delivery

develop
mode: continuous-deployment

release*
mode: continuous-deployment
tag: rc
This could actually simplify GitVersion by allowing us to simply support default conventions for different branch types via config and we can delete a heap of the hard-coded branch logic.

—
Reply to this email directly or view it on GitHub.

[JakeGinnivan]

@robdmoore that is true. We do have variables, but this would enable different branches to version differently. I.e master can still be cont delivery and others are continuous deployment

I also think it is an easier concept than variables

[JakeGinnivan]

There are a couple times when we have done this that we want to deploy (manually) a Pull Request build just to test out a few things before pulling into the develop branch.

The new config ideas could allow you to say pull request branches are not semver and use 4 part versions. What do you think of the suggested approach

Sent from my Windows Phone

---

From: Gary Ewan Parkmailto:notifications@github.com
Sent: ý09/ý12/ý2014 14:36
To: ParticularLabs/GitVersionmailto:GitVersion@noreply.github.com
Cc: Jake Ginnivanmailto:jake@ginnivan.net
Subject: Re: [GitVersion] GitFlow: Include commits in PreReleaseTag for release, hotfix and feature branches (#323)

When I am creating a release, I want to commit multiple times/submit multiple pull requests and when i am ready hit the deploy button which deploys the current version and then tags the vcs with that version.

There are a couple times when we have done this that we want to deploy (manually) a Pull Request build just to test out a few things before pulling into the develop branch. This works great the first time that you do this, but if you find that something is not quite right and go back and fix it, you can't then deploy the corrected pull request version, as the version already exists. In order to do it, we have to manually go and hack Octopus Deploy to delete the release, and associated nupkg packages, so that we can deploy again.

So it would definitely be nice if "something" can be done here to help with this edge case.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/323#issuecomment-66291103.

[gep13]

The new config ideas could allow you to say pull request branches are not semver and use 4 part versions

Ah, interesting idea, I hadn't concerned it from that side of things. Yes, I can see how that would work!

I definitely like the approach of everything being described/configured in the yaml file, that way it becomes an artefact of the repository it is in.

[RemyDuijkeren]

I prefer to have the option to override the InformationalVersion in the GetVersionConfig.yaml and command-line, just like #315. I think this could solve this issue and also some other issues.

If $version$ is used in the .nuspec. then NuGet will use the AssemblyInformationalVersion as version when we pack. But by default GitVersion has a very long InformationalVersion, like 0.2.1-unstable.34+34.Branch.develop.Sha.e1107f4d977b3f0bd25f6a322834eccff0efbc1b, which is not allowed by NuGet (to long?). NuGet then switches to AssemblyVersion for the $version, which is not something I want.

I know have to insert the version myself into .nuspec to override this behavior.

[JakeGinnivan]

This config approach is done. Check out the 3.0.0 branch

@remyvd I think that is a separate issue. Mind opening a new issue if it is still a problem with 3.0.0