Pulseeffects: Changelog?

[hackel]

I don't see a Changelog anywhere. I last installed version 1.4.2 and see that it's now already up to 3.0! Congratulations, that's a great achievement in such a short amount of time, but I'd like to see all of the hard work you've put into it since then, and what features are new or changed.

If you don't want to maintain a separate changelog file, you can document changes with each Github release. I find that this is very convenient for a lot of projects. It would certainly be easier than grepping the commit log.

Thanks, and keep up the good work.

[wwmm]

Hi! Unfortunately there is no changelog. I still have to get used to do them. How can I use github to do that? In any case a lot has changed since version 1.4.2. To the end user the most visible features are:

• Effects can be applied to microphone's output and the settings used are also saved to presets file.
• Meson replaced setuptools as build system (@AsavarTzeth work)
• we have a flatpak package (@AsavarTzeth work)
• Panorama, low pass and high pass plugins
• The user can select a dark theme
• The user can tweak frequency, bandwidth and type of equalizer bands
• Each plugin can be enabled/disabled and this state is also saved to presets
• Initial work towards some kind of simple room equalization using a calibrated microphone. It is very far from finished and not much useful to most users right now. I will focus on that on the next releases.
• Besides switching app on/off the user can also change its volume and mute state
• Many changes to the user interface

Lots of code refactoring were necessary in order to do that. But this is not something that the end users would see.

I am glad PulseEffects is being useful :-)

[hackel]

Thanks! The new version has been great until today when it stopped working, but that's a separate issue.

When you create a new release on Github, you can include whatever you want in the release description. I've just seen a lot of projects use that space for a changelog lately. It's still manual, not automatic by tag or anything.

[JP-Ellis]

I also would like to see a changelog.

There are several ways to do it, but I think the best one is to add a CHANGELOG.md file. You can see a nice way that this can be organized over a Keep a Changelog.

[wwmm]

I would like to see a changelog too :-) But I have to admit I have been a little lazy in this regard. Is there a way to automate part of the process? I am aware that just using a prettified git log is bad practice. But I do not believe we will ever have a changelog if I have to do the whole tracking by hand...

[JP-Ellis]

I think the best is to do just as they suggest at Keep a Changelog.

That is, having something of the form:

# Changelog

## [Unreleased]
### Added
- Applications: High Pass and Low Pass filter apps

### Fixed
- [Setting in App] is now compatible with [Other Setting]

### Changed
- Compressor algorithm: it is now more efficient and uses [New Library].

### Removed
- Setting [Foo] because [Reason].

## [X.Y.Z] - 2017-11-22
### Added
- Foo, Bar and Baz

In particular, having the Unreleased section means you don't have to recall all the features you added at release time, but you can progressively add them there.

Also, you don't need to log all changes in it (that's what the git log is for). If you just did some code refactoring which has no other effect (yet) on the final interface, then you probably don't need to log it, or at most have:

### Changed
- Refactoring code in preparation for [New Feature]

The main thing is to list changes which will affect the end user.

[wwmm]

Ok. I added a file CHANGELOG.md to master. Now I have to get used to it :-)