Setup Changelog / Release Notes

[Betree]

Release notes are useful to track what has been delivered and when. Setting this up should be simple enough and will ensure we don't forget changes when publishing news or newsletters.

Power users may also be interested in having a clear and concrete resume of what changed in the previous releases so they have a better understanding of what we are working on.

Specifications

• Should create a tag when we do npm run deploy:production
• Should be automatically done when releasing a new version
• Should group items by type (fix, feature...)

Progress

• Backend
  • Setup the changelog system
• Frontend
  • Add git tags when releasing
  • Setup the changelog system

[flickz]

Quite different from GitHub release note?

[Betree]

@flickz You mean this one? It would work, there are a lot of tools to do that and I'm not sure yet which one is the best for our case.

I'd love if we could offer a page like this: https://desktop.github.com/release-notes/

[alanna]

This would be great for the newsletter too

[flickz]

@Betree github-release-notes uses issues to create change logs, leveraging issue labels and milestone, creates a CHANGELOG.MD file. An example of the changelog generated by this module is https://github.com/ChurchCRM/CRM/blob/master/CHANGELOG.md.

But to achieve Github Desktop release note type, we might have to write the code ourselves, although we can adopt some of their code, they have an archived repository containing the code and it's also available within their Desktop repository. I also think the release note are written manually and auto added to changelog.json file.

What do you think?

[Betree]

Thanks for sharing the details!

I like github-release-notes, I'm using it on another project and it's working fine. A homemade solution with a pretty page would be great but that's a different complexity and the need is not strong enough in my opinion to prioritize it now (may be a good case for a bounty tho).

Starting with something simple like github-release-notes and improve when we feel the need feels like the right path to me.

[alanna]

Has there been any progress about this @Betree ? It would be super useful for making sure we are updating documentation as new features are released.

[Betree]

@alanna Not yet, I'd love to see that too but I don't have the bandwidth to lead / work on this project right now. It's also hard to put a bounty on it because the specs are not very clear.

[flickz]

From my previous attempt to solve this, we should be able to build custom solution that suit our needs, especially to enhance newsletter.

This hasn't really been a priority hence no progress. It should be an interesting weekend hack, I'll try to look into it again this weekend and explore new tools available.

[alanna]

@contraexemplo do you know of any good way to easily track changes in the app so we can also check that the docs have been updated? We've talked for a long time about needing a real changelog but have not had capacity for it. What do other projects to to achieve this in an easy and semi-automated way?

[flickz]

Update here, I've started work on this, I'm half way done, there should be a demo on Friday hopefully.

[contraexemplo]

@flickz hi! I'm really interested in the progress of this issue, do you have any updates and could you explain a bit what strategy you have in mind to solve this issue?

[flickz]

@contraexemplo So the goal is to have a page like this https://desktop.github.com/release-notes/ to achieve this, we'll be fetching closed issues weekly, display them in a url like changelog.opencollective.com as weekly releases.

The progress with this, the fetching aspect is done, what's left is having a UI to display them.

[contraexemplo]

@flickz that's a really nice idea, I like it a lot!

[znarf]

That's a really nice example.

[alanna]

I like this solution. If it's possible to move this forward soon, I think we should. It will help with many aspects of team collaboration and community communication. @flickz are you working on the UI?

@contraexemplo - once this is up and running we could start with a manual process of just checking the updates every week or month and making sure the documentation is updated accordingly.

I would also start using it immediately for newsletter updates.

[contraexemplo]

hey @flickz, any updates on this?

[flickz]

I didn’t get enough time to work on it previous weeks but it’s amongst our engineering Todo for this week so we should have a first version by Friday.

…

On Tue, Nov 19, 2019 at 10:06 PM Anna e só ***@***.***> wrote: hey @flickz <https://github.com/flickz>, any updates on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1674?email_source=notifications&email_token=ADX2XBMJEUCMWNM4NIISNUDQURIOXA5CNFSM4GSKRZ62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEPYRLI#issuecomment-555714733>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADX2XBOKQS3GRJKRGARNKGTQURIOXANCNFSM4GSKRZ6Q> .

[flickz]

The first version has been deployed: https://changelog.opencollective.com/

[flickz]

Closing this now. Project repository https://github.com/opencollective/opencollective-changelog

[contraexemplo]

Awesome job, @flickz! 👏 I'll add it to the docs.

[znarf]

The changelog project doesn't address any of the original specifications from @Betree .

[Betree]

While the solution implemented is different, I think that it covers the need that I had to track what we deliver. If being able to tag releases on the frontend is not a requirement, I'm ok with closing it.

[flickz]

If being able to tag releases on the frontend is not a requirement, I'm ok with closing it.

I think we can still find a way to work around this, I'll open a separate feature issue for it.