Isn’t it easier to create a
mixtask which firstly guess based on configurable prefix (let’s say: "fix: ") and then asks for a type of version change giving the guessed one as default (to just press enter)?
I thought about making an actual Elixir library to solve the issue at hand.
However, semantic-release is the industry standard battle-tested tool (was created almost 10 years ago and is the 128th most depended upon package on NPM, ahead of jquery, underscore, babel and lots of other staples), packs in a lot of useful features (e.g. support for pre-release / maintenance branches) and is highly configurable to suit almost any workflow.
For these reasons, while it would be extremely instructive to try and create an Elixir equivalent, I don’t think reinventing the wheel is a good use of time, especially when there is virtually no downside to using (and extending) the already available tooling.
Some projects would need to add
nodeas extra environment dependency which is not always a good idea.
Technically, because semantic-release is made with a CI-first approach in mind, it doesn’t have to ever be run locally. Because of this, the Node.js environment dependency is only in the release workflow file. Node.js is required locally only when initializing the tool, to install the packages and run the dry-run to check everything is working as expected.
Also obviously the documentation is not on
hexwith all of it’s side-effects which may be confusing especially for new developers.
I’m not sure what you mean by “side-effects”, but I don’t think not having the documentation on hex is an issue, since this isn’t an Elixir library per see, and the only place it will be referenced is in the release configuration. Similar to CI tools, where you wouldn’t expect GitHub Actions documentation to be on Hex, the relevant documentation is readily available where it’s most relevant.
Does it have any strict format or it’s configurable somehow?
This is fully configurable by choosing an existing conventional changelog preset, or creating your own by forking one of the existing presets and making adjustments as I did (to be exact it is a maintained fork) with @insurgent/conventional-changelog-preset (which includes all commit types and adds emojis before categories). You can take a look at the relevant source code in lib/commit-transform.js. But note that with all the available presets, you probably don’t have to create a new one.
Does it creates a
gittags automatically as well (git checkout v1.x.yor so)?
Yes, I forgot to mention that in the post, but semantic-release tags the version to the release commit before creating a GitHub/GitLab release, as it actually relies heavily on tags (e.g. to determine the current version).
What is the comment content? Is it configurable? How about
wiki?
You can take a look at an example comment here: semantic-release/semantic-release#3062 (comment).
It is also fully configurable, please refer to the semantic-release/github options documentation if you’d like to know more.
Regarding the wiki, I’m not sure what you mean by that. Could you please expand on the use case(s) you have in mind?
How about
InstallationinREADME.mdfile? It should be easy to find in markdown as long as you know the project name and previous version.
That’s actually a very good idea, thank you so much! I’ll be adding it to the feature requests and will start working on it as soon as it is specified correctly (btw if you’d like to share your views on features currently being specified/implemented, don’t hesitate to visit the Discussions/Issues for feature requests).
Those links are relative, so browser searches it on this forum …
Sorry about that, thanks for pointing this out I’ll fix them immediately.
Thank you so much for responding to my post to share your views and concerns, and I hope I’ve addressed them as best as possible 
