Provide better changelog/release notes

[FrankyBoy]

Because quite frankly, the current release notes are a disgrace.

[kzu]

Thanks for your feedback.

I'll make sure to prioritize this better above having a life with my wife and 3 kids, having a full time job and other personal oss projects and focus instead on this one open source project so that you're happier :p

In the meantime though, you know, it's open source and anyone can contribute anything they think will make things better. Just sayin'...

Could be a commits/issue fixes to release notes generator or whatever. I'm all for it.

[FrankyBoy]

Hey mate, I do realize you have a busy life, but don't be salty. The thing is, I couldn't make a changelog even if I tried, because it seems there are no tags or other structure that would indicate which revision actually corresponds to which release (at least not here on github).

[kzu]

if you want to volunteer, I'm all for adding more repo admins ;)

Then you get to play with milestones, tags, releases or whatever!

[kzu]

FWIW, this project was started (and pretty much "completed" back in Google Code's day, hence the lack of organization around GitHub's great project management support :(

[FrankyBoy]

Ah, yeah, those were the days, right? ;)
Anyhow, just did some little investigation and found that the DLL's Product Version contains the short hash from git, so based on that I could try to update the changelog. No promises though, busy weekend ahead.

[FrankyBoy]

So I looked around the project and history a little bit, tagging the current releases (not sure where the current -alpha builds come from, guessing you just have these revisions locally?). Considering that most releases are just one or two changes I'd say the best (cheapest) solution is to automatically add a tag when you publish. I.e. in the build.proj Publish target running git tag $(Version) and then ideally automatically pushing it with git push $(Version).

[kzu]

we push on commits to master, so tagging wouldn't be too useful.

[stakx]

I believe that release tags in the repository would still be helpful as a quick aid. People who haven't done some digging in the repository simply won't know how to correlate NuGet package versions with commits in the Git repository.

I think three small changes could really improve the release tag situation in the future:

1. Let the CI server automatically add a version tag to the Git repo whenever it pushes a new package to NuGet. (We will have to take care of tags for already published packages.)

2. In order to make releases and thus version tags more meaningful, let's not produce a new package version too often. Let's be more careful when we add commits to the master branch, and let those commits not be trivial changes. We can try to let commits accumulate in a different branch (say develop) until we're ready to release a new version.

3. develop should become the default branch, so that GitHub will suggest that branch as the target for new pull requests.

[kzu]

👍

On Sat, Jun 3, 2017 at 5:14 PM stakx ***@***.***> wrote: I believe that release tags in the repository would still be helpful as a quick aid. People who haven't done some digging in the repository simply won't know how to correlate NuGet package versions with commits in the Git repository. I think three small changes could really improve the release tag situation in the future: 1. Let the CI server automatically add a version tag to the Git repo whenever it pushes a new package to NuGet. (We will have to take care of tags for already published packages.) 2. In order to make releases and thus version tags more meaningful, let's not produce a new package version too often. Let's be more careful when we add commits to the master branch, and let those commits not be trivial changes. We can try to let commits accumulate in a different branch (say develop) until we're ready to release a new version. 3. develop should become the default branch, so that GitHub will suggest that branch as the target for new pull requests. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#320 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKW61KTjqYj3D885Y_LKeK3WqWxcicXks5sAb6ngaJpZM4L07lo> .

--

…

-- /kzu from mobile

[stakx]

As noted in #247, I've now added tags for the more recent releases (versions >= 4.5.0).

[stakx]

I'm currently looking at http://keepachangelog.com/en/0.3.0/ and their recommendations sound good to me. What does everyone else think, would those be good conventions to adopt for Moq?