Release note for multiple tags has earliest at the top instead of bottom

[pvandervelde]

The release notes currently have the 'vNext' version at the top but all other tags are ordered by date starting with the oldest. I would expect that the oldest would be at the bottom.

[pvandervelde]

Would be happy to provide a pull request if this indeed deemed a problem.

[JakeGinnivan]

Oldest should indeed be at the bottom

but vNext should be all unreleased and new issues/items?

Happy to have a PR anyways if it is not working correctly. I have been refactoring and it needs some love to make it really ready to go (hopefully this week, been distracted with GitVersion)

[pvandervelde]

It looks like the current HEAD is doing something completely different from the last release (on NuGet.org). The versions are now in the expected order (earliest release at the bottom, latest at the top with vNext above that), but the issues are now all under the incorrect release, while the latest release places them in the right spot.

An example from my library from here: https://github.com/pvandervelde/Nuclei

Current release

vNext

• Automatically create release notes from resolved Github issues #22 +enhancement
• Switch versioning scheme to use Semantic Versioning #14
• Nuclei.Communication: Provide way to detect expired messages #7 +enhancement
• Nuclei.Communication: Version the communication protocol #3 +enhancement

V0.6.7.0 (23 October 2013)

• Nuclei.Communication: Commands returning a continuation task fail upon transfer to the invoking endpoint #1 +fix

V0.7.0.0 (04 December 2013)

• Nuclei.Diagnostics: Allow grouping of timing results #2 +enhancement

V0.7.1.0 (21 December 2013)

• System.ServiceModel.ProtocolException: The channel received an unexpected fault input message while closing. #9 +fix

---

current HEAD

vNext

• Provide way to detect expired messages 25
• Issue/releasenotes 24
• Automatically create release notes from resolved Github issues 22 +enhancement
• Switch to using the proper GitHub branching model with use of pull requests for everything 15
• Switch versioning scheme to use Semantic Versioning 14
• Nuclei.Communication: Endpoint connection should be verified before use. 11 +fix
• Nuclei.Communication: Discovery process should be based on a URI only 10 +enhancement
• System.ServiceModel.ProtocolException: The channel received an unexpected fault input message while closing. 9 +fix
• Nuclei.Communication: Provide way to detect expired messages 7 +enhancement
• Nuclei.Communication: Version the communication protocol 3 +enhancement
• Nuclei.Diagnostics: Allow grouping of timing results 2 +enhancement
• Nuclei.Communication: Commands returning a continuation task fail upon transfer to the invoking endpoint 1 +fix

Commits: 76ebf13802...6409b2e74c

V0.7.1.0 (21 December 2013)

• Nuclei.Diagnostics: Allow grouping of timing results 2 +enhancement

Commits: 6cbeb3ada2...a341db15ad

V0.7.0.0 (04 December 2013)

• Nuclei.Communication: Commands returning a continuation task fail upon transfer to the invoking endpoint 1 +fix

Commits: 6f8e882b14...1bc23750b9

V0.6.7.0 (23 October 2013)

Commits: dacc5de428...55861813f5

V0.6.6.0 (12 October 2013)

Commits: 4f9c6a96e3...8bc7d22d72

V0.6.5.0 (26 September 2013)

Commits: f90aa2374a...83a270ab2b

V0.6.4.0 (21 September 2013)

Commits: 4be90ee562...dd6791c6f0

v0.6.3.0 (22 August 2013)

Commits: 9ca7f5517e...76e96bc68b

v0.6.1.0 (16 August 2013)

Commits: 2f407131b5...53d38a9972

---

I suspect some of the problems with the issues being releated to the wrong releases (for v0.7 and v0.7.1) is because I possibly didn't close the issues until after the release (which is my fault for following a slightly bad process), but the released version of GitReleaseNotes got that right.

So in short it seems that the current issue is fixed in HEAD but the current HEAD introduces a new problem in that the issues are not related to the correct releases. So not sure what to do with this issue now.

[JakeGinnivan]

Thanks for looking into this!

So, the new behaviour is that it will start appending to the releasenotes.md in the root (or whatever you output to) rather than regenerating.

This means you can use it to generate it over and over, as well as manually move things into the correct releases/fix titles etc and it will simply append the new closed issues.

vNext is basically anything which doesn't fit, and there are probably some issues. vNext should include the current date against it so it knows when it is up to, then it really can just append.

I haven't figured out about turning vNext into the next tagged version, which is a large issue. I will try to get back to it over the next week, but feel free to jump in, write tests, suggest behaviour or fix problems :)

[JakeGinnivan]

Oh, also pull requests are now included, which may cause more noise than the previous

[pvandervelde]

Ah right now it makes sense. I still think it would be nice if there was some way to mirror was the current release does, i.e. include issues in those releases where the commits are for if the issue was closed just after the release because I used to close my issues after the release with a comment pointing to that release (e.g. "closed in v1.2.3.4").

One other thing I would like is if it were possible to generate the complete release note (including the version for vNext, i.e. if I know vNext = 1.2.3.4, then have that verison number) so that I can generate the release note before tagging & releasing

[pvandervelde]

Closing this because the current code does this correctly.