While I still believe this to be a bug, this could also be a feature request to add BitBucket server and cloud to the HVCS options. I haven't had any time to look through the code, so I don't know if the bug is easier than the feature.

This issue is stale because it has not been confirmed or planned by the maintainers and has been open 90 days with no recent activity. It will be closed in 7 days, if no further activity occurs. Thank you for your contributions.

This issue is stale because it has not been confirmed or planned by the maintainers and has been open 90 days with no recent activity. It will be closed in 7 days, if no further activity occurs. Thank you for your contributions.

Still an issue/feature-request.

@chet-manley, first, thank you for being one of the few people to respond to the stale activity just added!

Secondly, as of v9.1.0, Bitbucket is now a supported hvcs, the URL problem likely is fixed for you now (unless it's issue vs PR url differences). Please check it out when you can.

Also, we do not support a pre commit command any more relating to publish. Likely you will need to switch to use the version sub command for your desired actions. See the v7 to v8 migration documentation page for full details.

Let me know if PSR now fits your needs.

Finally had the time to look into this, and I've gotta say, the 7 -> 8 changes are significant. I believe I have overcome most hurdles, but am stuck on two significant showstoppers.

• Changelog
  • My current changelog was built entirely using PSR up to v7. With v9.8.1, running semantic-release changelog overwrites the entire changelog, back to initial commit. This created a multitude of issues. First, the commit links were incorrect. Yes, it used the remote domain from config (and I have type set to bitbucket), but the paths were all wrong., so I will still need to sed the changelog on every update.
  • Pre-v8 versions only log commit types that trigger version changes (docs, fix, refactor, et al), but v9.8.1 logged everything. Every single commit went into the changelog, including ones simply labeled "unknown", even though I have minor_types = [ 'feat' ] and patch_types = [ 'docs', 'fix', 'perf', 'refactor' ] set in the commit_parser_option config.
  • Most importantly, I had (wrongly) assumed that not setting a template would result in a changelog matching the pre-v8 style. However, I can't find anything in the migration docs about how to retain the old style of changelog.
• Error: No release will be made, <current version> has already been released!
  • I have made multiple fix, refactor, and docs commits since the last version (released with PSR v7.33.x), but v9.8.1 refuses to release a new version, even though it finds the last one. And yes, I did create branches configs for my release branches.

All-in-all, I think the provided 7 -> 8 migration docs misses on some very key differences between the versions, unless I completely missed something obvious.

• My current changelog was built entirely using PSR up to v7. With v9.8.1, running semantic-release changelog overwrites the entire changelog, back to initial commit. This created a multitude of issues. First, the commit links were incorrect. Yes, it used the remote domain from config (and I have type set to bitbucket), but the paths were all wrong., so I will still need to sed the changelog on every update.

Yes, the changelog command and version command run a full changelog regeneration (this has its problems, see #858, #722). I will need to know what was incorrect (expected vs. actual) about your paths to the commits. Since you have set the type to BitBucket, the code is attempting to create the correct path to the commit url (the filter function:

• Pre-v8 versions only log commit types that trigger version changes (docs, fix, refactor, et al), but v9.8.1 logged everything. Every single commit went into the changelog, including ones simply labeled "unknown", even though I have minor_types = [ 'feat' ] and patch_types = [ 'docs', 'fix', 'perf', 'refactor' ] set in the commit_parser_option config.

Yes, that is the current default as of v8. I don't agree with the default but I haven't gotten around to changing it. You will want to set the semantic_release.changelog.exclude_commit_patterns array with regular expressions that ignore undesirable commits to include in the changelog. You can refer to my new defaults in pyproject.toml.

• Most importantly, I had (wrongly) assumed that not setting a template would result in a changelog matching the pre-v8 style. However, I can't find anything in the migration docs about how to retain the old style of changelog.

Yes, the old style changelog was not retained, see #737. I became the maintainer after v9.0 released, but was not around for the v8 migration, my knowledge is limited here. The jinija2 template is fully customizable so you should be able to build one like your last, and I've provided a number of extra filters to the environment for ease of use. Probably will add some more in upcoming releases.

• Error: No release will be made, <current version> has already been released!

  • I have made multiple fix, refactor, and docs commits since the last version (released with PSR v7.33.x), but v9.8.1 refuses to release a new version, even though it finds the last one. And yes, I did create branches configs for my release branches.

This could be many different things (branching strategy, merging strategy, commit syntax). I usually request the log generated via semantic-release -vv version command and the result/graphic of your git tree using either a Git client or git log --graph --oneline --decorate --all. This should be with the resulting version tag removed (ie prior to when psr makes a tag/commit of the desired version). And lastly, please post your semantic-release configuration.

This issue has not received a response in 14 days. If no response is received in 7 days, it will be closed. We look forward to hearing from you.

This issue was closed because no response was received.

Looks like I didn't respond in time, work has been very busy. Probably fine to leave closed though, as my OP is two versions old and no longer relevant to the project. Hopefully I can use your suggestions to perform some more testing, although I must say it would be really nice if the default Changelog formatter matched the old style without having to write my own (I may end up waiting for #737). That should definitely be mentioned in the migrations docs for people stuck on v7, as it is probably the biggest breaking change and takes considerable work if you don't want to lose thousands of lines of formatted changes.

@chet-manley, I have no problem opening the issue back up. Or just open a new issue related to your issues with v8 or 9.

The docs can always be better, and I can see if I can add to that migration docs for the changelog topic.

I also requested a git tree of your repo where you don't think the version was calculated properly.