chore(master): release 0.5.0

[kristijanhusak]

🤖 I have created a release beep boop

0.5.0 (2025-02-01)

Features

• Add support for footnotes (#874) (4f62b7f)

Bug Fixes

• archive: Set correct archive category on archived headline (63d2cbb), closes #882
• refile: remove unnecessary escaping for refile autocompletion (d56c691), closes #877
• remove double ts parsing (b587545)

---

This PR was generated with Release Please. See documentation.

[ficcdaf]

The workflow seems to be working fine!

One drawback is that the changelog file only "starts" from the point at which release please is enabled. So, if we want the changelog to contain the changes from previous releases as well, we would need to manually add them to the changelog file before merging this PR.

Do you think that's worth adding previous releases to changelog file? Personally I don't think it matters very much, but I thought I should point it out. @kristijanhusak

[kristijanhusak]

@ficcdaf Yes, it seems to be working good.
I'd like to tweak a few things if possible, though. I can't really figure out from the documentation, so you can maybe help:

1. I know it's semver, but is there a way to force it to increase only patch versions? At this pace we will get to a 0.10 or bigger soon, and I'm not really introducing that many breaking changes that would justify increasing the minor version.
2. Probably far-fetched, but is there a way to have it create an org file for changelog, and maybe in a different location?

I'm probably asking too much at this point, but I want to check before proceeding.

[ficcdaf]

@kristijanhusak Hmm... As far as I can tell, this is standard semver (breaking changes increase major, features increase minor, fixes increase patch).

I'm not sure if it's possible to change the versioning style, but admittedly I haven't looked into it. Does this repo intend to follow zero versioning like Neovim, or are you inherently not opposed to semver?

It may be possible to change the rules such that features and fixes both increment patch number, and breaking changes increment minor, and major is only incremented manually. Personally I don't like the idea (I think semver is very valuable) but if this is your preference I could try looking into whether it's possible.

In terms of the changelog file, that's an interesting question. There may be an option to specify the changelog file's location, would need to check the docs.

In terms of the org format, my guess is that release please is really unlikely to support this directly. However, we could try adding another task to the workflow, one that parsers the changelog.md file created by release-please and converts it to org format. I would imagine there is no way to avoid keeping the original changelog.md though, because the workflow needs a file it can parse and append to.

Personally, I think this (the org format) would be more trouble than it's worth -- but of course you are the maintainer and you understand the needs of this project better.

[kristijanhusak]

I'm not sure if it's possible to change the versioning style, but admittedly I haven't looked into it. Does this repo intend to follow zero versioning like Neovim, or are you inherently not opposed to semver?

I'd prefer to follow zero versioning like Neovim for the time being, because in my opinion, a major version is something that is feature complete and stable.
It's not that it's not stable, but I think it's far from feature complete, when compared to the Emacs org mode.
It's still a long road before this hits a v1.0.0

I'll think about this a bit more and maybe introduce a different tool that would give me more control over it. Until then, this will help me collect a changelog for the next release.

Sorry if this is a bit disappointing, but I wasn't really familiar with this "release please" github action, so seeing it how it works helped me understand it better, and understand the needs for this to be done.

[ficcdaf]

That's okay. If you want, I can look into whether release please allows us to specify the versioning style like you specified. Intuition tells me it should be possible. If anything, I feel like it should at least allow us to only automate the change log and let maintainers specify the version numbers.

There seem to be a lot of advanced configuration options. So we just need to find it in the docs. I can take a look later.

[kristijanhusak]

@ficcdaf I ended up creating a custom script + workflow to take care of this:

1. Script - https://github.com/nvim-orgmode/orgmode/blob/master/scripts/generate_changelog.lua
2. Workflow - http://github.com/nvim-orgmode/orgmode/blob/master/.github/workflows/release.yml

This allowed me a few things:

1. Specifying version number manually
2. Generating changelog in org format
3. Populating release information on the release itself (example: https://github.com/nvim-orgmode/orgmode/releases/tag/0.4.2)

I also populated several versions back to have some history, it's all u here: https://nvim-orgmode.github.io/changelog

I'm closing this PR since it's no longer useful.

Thanks for your help anyway, it gave me some good ideas how to handle this in the best way.