Cake build - Don't hard code gitreleasenotes.exe path.

[dazinator]

Fixes #1430

[dazinator]

@gep13 - how about this?

[gep13]

LGTM!

[gep13]

@dazinator let's give it a try 😄

[gep13]

@dazinator so, I am not sure what is going on here. I will try to look at it and figure out what is going on....

[gep13]

@dazinator so, the short answer is, I don't know what is going on, or whether this has worked in the past. I am not very familiar with GitReleaseNotes. We would really need some input from @JakeGinnivan on what to do here. I can get the build to work locally by creating the build/releasenotes.md file, but once the build completes, the file contains the following:

No issues closed since last release

Which I don't think is right, as I would have expected some issues to be present here. We can make the build pass by creating that file, but I would like to know what is going on in GitReleaeNotes.

@JakeGinnivan are you around to provide anything on this?

[gep13]

Link to latest failed build:

https://ci.appveyor.com/project/GitTools/gitversion/build/4.0.1-beta.1+2.build.1597#L394

[JakeGinnivan]

Some ideas, maybe checked in version is different to latest published? Also, why is it looking in /build ?

Interesting the version: 4.0.1-beta.1+2.build.1597 - did we release v4?

The basic idea of gitreleasenotes is, look at the previous tag, get the date, query closed issues since that date, drop that into the releasenotes.md - it's supposed to be quite basic and dumb, think it got over complicated at some point adding support for a bunch of different providers and such. Could remove this part of it, then just run it manually until a better way can be put in place

[gep13]

@JakeGinnivan I am going say that I don't know anything about how the releasenotes side of things were/are being handled, so I can't offer anything there, sorry.

@dazinator @asbjornu might be able to help with the version number question.

[asbjornu]

I'm not aware of any stable v4 release as of yet, no. 😄

[gep13]

So, looks like the issue is coming as a result of the merge of the PR for .netstandard. The build is dogfooding the use of GitVersion, and looks like something is off.

[gep13]

Is the the name of the branch that is throwing it off?

[gep13]

i.e. hotfix/4.0.1

[gep13]

@dazinator @asbjornu @JakeGinnivan so yeah, I think that is the issue:

https://ci.appveyor.com/project/GitTools/gitversion/build/4.0.1-beta.1+2.build.1597#L288

We might need to add some entries in the GitVersion.yml file to exclude those.

[dazinator]

Yeah the netstandard PR must have bumped the major version to 4.0.0. When I subsequently did the build fix pr's today I saw master was now at 4.0.0 so i created 4.0.1 branch to do this fix. I think what we want is to prevent the major bump in the first place then. I thought maybe there was a commit message bump in the netstandard pr but a quick glance and I couldnt see it.

[gep13]

@dazinator just so I am clear...

A major bump for the next release is fine, right?

I am happy with 4.0.0-beta. What I think is wrong is the patch bump to 4.0.1-beta.

[dazinator]

Oh right.. Yeah I thought the issue was why we went to 4.0.0 in the first place :-)

I dont think it much matters. We added support for other platforms and a lot did change so perhaps a major bump is warranted (to 4.0.0) but there should be no breaking changes so in that sense the major bump wasnt really mandated. If we are happy to stay at 4.0.0 i'm fine with that. I guess then we just add that 4.0.1 hotfix sha to the gitversion file right?

[gep13]

@dazinator Yip, that would be my understanding, yes.

[arturcic]

It seems like the gitreleasenotes.exe cannot generate the release notes because of this GitTools/GitReleaseNotes#111

[gep13]

@arturcic ah, that could well be the issue! @JakeGinnivan are you in a position to release a new version of GitReleaseNotes?

[JakeGinnivan]

Released, thanks @arturcic

[arturcic]

You're welcome

[arturcic]

There is a PR using the new GitReleaseNotes and skips the commits related to version 4.0.1
#1438.
@gep13 could you have a look?

[dazinator]

Looks like this fixed the build, but I can't see the packages released to nuget.org yet. Do we want every new build of master to go straight to nuget.org, or is it a manual choice to do the push from master?

[asbjornu]

I’d like every push to master to end up as an unstable build on every package repository that supports unstable/prerelease packages.

[gep13]

@dazinator @dazinator @JakeGinnivan personally, I don't think that every commit into master should be pushed out, since not every commit onto master will warrant a new release. As an example of what I mean, I have just merged this PR (#1338) where @JakeGinnivan added some information about the release process that is currently in play, and how it is possible to get a release onto NuGet.org. This in itself doesn't warrant a new release, as it is purely a documentation change, no binaries would have been updated. I would much prefer it to be an informed decision by one of the maintainers to push out a release to NuGet.org. Having said that, I would have no problem with every commit on the master branch resulting in a release to say MyGet.org, where people who are interested in testing out the latest bits could consume a package from.

Thoughts?

[asbjornu]

I don’t think it’s important to be careful and give much thought to prereleases; much better with one prerelease too many than one too few. Not having to perform any manual steps to get a prerelease out the door means the barrier to do it is zero, so it will be done all the time. Whenever you introduce a manual step, you introduce barrier and it will stop releases that should have preferably been out but isn’t due to the people remembering how it’s done is on vacation, or whatever.

I think stable releases warrant a tag, though. Nothing more, preferably. Every tag should have an accompanying release with release notes on GitHub, but I don’t think we can fully automate that, so I’d rather have stable releases without release notes than no stable releases at all.

I think this is what’s required to get out of the current situation of only @JakeGinnivan being able to publish releases.

[dazinator]

@asbjornu @gep13
I am more aligned with @asbjornu on this for many reasons some of which he mentioned.
To @gep13's point, the pre-release packages need not go to nuget.org - they are already going to the appveyor feed I beleive. However in my experience its more convenient to push pre-release packages to nuget.org as people already have that set up as a feed, so it saves them setting up a new feed (myget / appveyor etc).

So how about this:

• Stable packages (master branch, tag) -->nuget.org
• Unstable packages (master branch, no tag) -- > nuget.org "pre-release"
• Unstable Packages (any other branch) --> appveyor ci feed.

Would gitversion calculate an unstable version number for a build of master branch and no tag though?
I personally would use gitflow, but I use that for everything :-)

[asbjornu]

I don't have the full overview, but from memory I know that GitVersion exists on Homebrew, Docker and Visual Studio Team Systems already. Probably more. All of these should also be updated as often and automatically as possible, with pre-release packages if they support them. Otherwise, I agree, @dazinator. 👍

Would gitversion calculate an unstable version number for a build of master branch and no tag though?

I believe that's the default behavior for mode: Mainline, but I too am more familiar with GitFlow, so I'm not sure.

[dazinator]

I will create a seperate issue for sorting our automated deployment out.
At the moment we have some PR's and issues blocked because we don't have a handle on automated releases!