changelog
changelog copied to clipboard
semantic-release
Feature - control branches on which to generate a change log.
Disable building of change log for specified branches while still performing the other release functionality. resolves #156, resolves #51
Why not just use array instead of comma separated string on ignoreBranches, while we are using json object as configuration parameter?
Why not just use array instead of comma separated string on
ignoreBranches, while we are using json object as configuration parameter?
happy to make that change, especially if it gets this feature merged
I am in need of this feature. How would you feel about the option being "branches: [...]" (as opposed to ignoreBranches)? This would have symmetry with the top-level "branches" array in .releaserc. I imagine the repos that would use this would have a list in mind where they do want the changelog modified, and a longer list of branches where they don't.
diff --git a/.releaserc.json b/.releaserc.json
index 094a34a..f5eb394 100644
--- a/.releaserc.json
+++ b/.releaserc.json
@@ -6,6 +6,7 @@
"@semantic-release/changelog",
{
"changelogFile": "CHANGELOG.md",
+ "branches": ["master"]
}
],
+1 Looking for this too. I can put in a workaround mentioned in #51, but would love to see this supported OOTB. Nice work @newbish
Why did you close it? Is it done or don't you want to wait for approvals anymore? 🙈
Why did you close it? Is it done or don't you want to wait for approvals anymore? 🙈
Realized it wasn't working the way I wanted it to. So did some rewrite since I needed it working and wanted to get a version in NPM ;)
https://www.npmjs.com/package/@newbish/changelog
Feel free to test it out and see if it meets your needs, I was using this repo to test: https://github.com/newbish/changelog-test
Hi everyone! Any reviewer to take a look into this?
@newbish could you resolve the conflicts?
I feel like having the option to filter all plugins by branches:[...] would be a good thing.
Is this also possible with this PR or does it only work with the changelog plugin?
I feel like having the option to filter all plugins by
branches:[...]would be a good thing.Is this also possible with this PR or does it only work with the changelog plugin?
This only affects the changelog, I believe the other plugins would have to implement something similar to have that capability.
This only affects the changelog, I believe the other plugins would have to implement something similar to have that capability.
Do you think there is some way to implement this for all plugins at once in the core library?
I believe some changes to files formatting could be out by this time.
attempted to apply prettier to match current formatting.
@newbish awesome PR 🎉 @alexsanderp, @gr2m it is possible that we merge this PR, it would be really awesome 🙏🏼
Anyone from the semantic-release team? @boennemann @UziTech @keplersj @kbrandwijk
@alexsanderp, thanks for the approval, however, looks like it requires maintainer approval.
LGTM but I don't have write permission for this repo.
any chance you can tell who has maintainer?
LGTM but I don't have write permission for this repo.
any chance you can tell who has maintainer?
When looking at previously closed PRs, you can see one was closed and approved by @travi in 2021
Dunno of he's still a maintainer but might be worth a shot
i'm sorry that there hasn't been much maintainer activity on this thread, but our maintenance team has been very busy and unable to keep up with all of the activity across the projects.
i think it is important to point to a few key points from our contributing guide:
- https://github.com/semantic-release/semantic-release/blob/ab45ab1f8d0d0f728fb026a92ec191bcc88f51f1/CONTRIBUTING.md?plain=1#L55
- https://github.com/semantic-release/semantic-release/blob/ab45ab1f8d0d0f728fb026a92ec191bcc88f51f1/CONTRIBUTING.md?plain=1#L68
in the various threads that are linked from this PR, i do not find any mention of this feature request being approved by a maintainer. i also do not find any responses to maintainer questions for clarification around why the feature is needed for supported workflows. instead the described desire details workflows that are not officially supported uses of the pre-release workflow functionality. pre-releases are intended for situations like confirming a breaking api change or rare changes that cannot be tested in isolation because of built tool changes or similar. pre-releases are not intended to be used to enable workflows similar to gitflow where every change starts as a pre-release to enable verification through the package consumers before promoting to the stable release line. keep in mind that semantic-release is not a generic workflow tool, but an opinionated tool that is intended to encourage continuous deployment style practices and simplify semantic versioning and the communication of the impact of those changes. even if we were targeting a more generic workflow tool, decisions have to be made to keep the project maintainable.
as mentioned, our maintenance team has not been able to keep up with all activity, so we have to make decisions around priority. unsupported usage naturally gets prioritized lower than supported usage. without the information requested in our contributing guide, we are left to assume that the request is to enable unsupported workflows like i describe above. we have not closed this PR because we are not deciding yet that this will never be implemented, but it is being treated as lower priority based on the information we currently have. if the assumptions are being made with incomplete/incorrect information, the next step should be to provide a more complete description of the desired use case and why it falls within the supported workflows. in order for a change like this one to move forward, the maintainers need to agree that it is valuable to the project and is worth the additional complexity and maintenance burden moving forward.
