Adding change logs for few last merged PRs and create tags for them about nerdtree HOT 10 CLOSED

it is the last PR mentioned in the change log #1269, and here are the PRs that missing a change log and tag release: #1306, #1330, #1363, #1365.

from nerdtree.

@alerque

from nerdtree.

Personally I see the value in changelogs for some projects, but generally not my editor plugins. The plugin managers I use show me the Git shortlog any time I update plugins.

I also have no objection to a changelog being maintained if somebody either wants to take ownership of it or sends contributions to it. If you want to backfill the changelog with the things that have been missed, go for it.

from nerdtree.

@alerque I agree changelog itself doesn't do anything important especially when it's only a line of description for each release, but keeping a tag for every release can help when someone wants to rollback to a specific version.

from nerdtree.

keeping a tag for every release can help when someone wants to rollback to a specific version.

This is sort of true, but is really only meaningful if the tags are not on every commit! For a long time the flow in this repo has bee to tag basically every commit that landed on master. I don't think that's a very useful kind of tag, in that case why not just use the commit SHA? Tags are great as markers for specific states, but I would imagine releasing them a little more periodically will give people tracking HEAD a chance to get the latest while people that don't want any churn might stick to tags.

More importantly I think the fact that more plugin managers are moving away from HEAD and towards using tags if they exist (looking at you lazy.nvim) is pushing plugin developers to use tags. Also some distros package plugins, and tags definitely help them.

My suggestion would be to ditch the changelog, still try to keep HEAD in a known-working state at all times, but only periodically add new tags for batches of changes without letting unreleased stuff sit around too long but giving it a little bit of a chance to shake out issues too.

from nerdtree.

One way of doing it can be keeping the changelog as it is but only releasing a tag on each minor update instead of on every patch. This way we can honor the old format of the changelog file while making releases more impactful, containing stable changes in them.
On the other hand, giving patch numbers to each commit while the commit hash exists is pretty redundant work, The only reason I want to keep the current CHANGELOG.md format intact is because of the nerdtree#version() function as it is right now, It uses the content of CHANGELOG.md to find out the current version of running NERDTree instance. If we want to change the changelog format or remove it altogether we need to figure a way out to keep track of the current version.
Do you have any suggestions on this subject?

from nerdtree.

I've created a draft PR #1377 for this change, But first, let's make sure we would want to keep using it going forward.

In case we want to keep using CHANGELOG.md I have a few suggestions.

1. I think after Phil stepped down bumping the MAJOR version in honor of ending an era is appropriate. A nice major version change can show clearly what was the last update under Phil's authority
2. We could create a tag only for 7.0.0 and keep the PATCH version only for nightly releases
3. Every few PATCH we can either bump the MINOR version or create a separate tag for the patch.
4. If we only tag MINOR versions, Separate patches can be accessed directly via their commit.

Let me know whether you think it's a good approach or not, To be honest, I'm not really sure about it.

from nerdtree.

I would like to add that I think changes to GitHub files for example ci shouldn't be mentioned in the change log. We should only keep it for the plugin changes.

from nerdtree.

Yes, that is one advantage of a changelog over git log, you can leave out irrelevant noise.

For projects that have a lot of commit action and relatively rare releases that becomes increasingly important. For such cases I typically prefer to setup an automatic changelog generated based on conventional commits using git cliff or npx standard-version, but I think that might be overkill for this project with the relatively podunk pace of maintenance. That being said if somebody wanted to go that route and was going to set it up and help coach PRs through using consistent commit messages I wouldn't object. Again I don't use or develop this plugin actively and am just around as a facilitator.

from nerdtree.

...and at this point you're the most active maintainer, so go for it. Maybe document what the workflow is going to be and update the PR template to match.

from nerdtree.