Side note: is there a reason the emoji id (like 👷) is used instead of the actual emoji

Just commenting as a user here, but I do personally think having:foo: vs the actual emoji just seems safer to me somehow 🤷. Seems like it could be less likely for problems to come up around encoding or viewing the files at any rate.

I like the idea; might even be good to bake in some common non-triggering types as defaults (even for non-triggering types like docs / ci / chore)?

Yeah for defaults I (at least think I) added:

• :pencil: for docs (I use 📝:memo: but the tests here already mentioned:pencil: relating to docs so I kept it)
• :construction_worker: for cicd
• :recycle: for refactoring

Wasn't sure how far to take the defaults. I like gitmoji for reference (and used it for defaults other than what's noted) but I personally deviate a little and think simpler is better, as there can be some overlap/ambiguity when there's too many (and at some point it's annoying to remember them all when they get super specific). I think it'd at least make sense to change:pencil: to:memo: to match gitmoji.

other_tags seems fine; maybenon_triggering_tags or something similar could also work?

Yeah wasn't sure what to call it. I looked at how the other parsers worked but I preferred how the emoji parser didn't double up with anall list.non_triggering_tags also makes sense.

Just commenting as a user here, but I do personally think having :foo: vs the actual emoji just seems safer to me somehow 🤷. Seems like it could be less likely for problems to come up around encoding or viewing the files at any rate.

Yeah figured it was something along those lines -- just wanted to make sure I wasn't missing any specific risks when I use emoji themselves, as they seem to render everywhere I need them to (whereas the codes don't render in pycharm, for example). Also harder to have a typo when using actual emoji. Easy enough to customize so I don't think it's an issue, was just curious. 👍

went ahead and swapped:pencil: with:memo: and changedother_tags tonon_triggering_tags

Sorry for the delay, been traveling, hopefully get to the review this week.

Initially, I'm not seeingany (there are some adjustments to constants) testing changes related to the changelog generation you were hoping for so have you considered how to validate your fix and how to prevent it from regression later on? I do realize some of the changelog testing is complicated.

Sorry for the delay, been traveling, hopefully get to the review this week.

Initially, I'm not seeingany (there are some adjustments to constants) testing changes related to the changelog generation you were hoping for so have you considered how to validate your fix and how to prevent it from regression later on? I do realize some of the changelog testing is complicated.

Yeah was tough for me to parse the testing structure. I did add/edit these intest_emoji.py:

        # No release with specified emoji        (            ":memo: Documentation changes",            LevelBump.NO_RELEASE,            ":memo:",            [":memo: Documentation changes"],            [],        ),        # No release with random emoji        (            ":construction: Work in progress",            LevelBump.NO_RELEASE,            "Other",            [":construction: Work in progress"],            [],        ),

My understanding is that this does test a commit message's effect on both the type of release and how it appears in changelogs. The first tests to make sure 📝 puts it under the 📝 header because 📝 is defined in the defaults. The second uses 🚧, which is not in the defaults, so it tests to confirm it's under theOther header (how it worked before this change).

Sounds like I'm missing something though?

This PR is stale because it has not been confirmed or considered ready for merge by the maintainers but has been open 60 days with no recent activity. It will be closed in 10 days, if no further activity occurs. Please make sure to add the proper testing, docs, and descriptions of changes before your PR can be merged. Thank you for your contributions.

I'm sorry, this was my fault, I was extremely busy the past two months and I didn't get back to reviewing this PR a while back. I will review more over the weekend. I appreciate your contribution to the project.

It has been 60 days since the last update on this confirmed PR. @python-semantic-release/team can you provide an update on the status of this PR?

It has been 90 days since the last update on this confirmed PR. @python-semantic-release/team can you provide an update on the status of this PR?