You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've recently made the decision to start evolving towards Elixir as my primary language (for various reasons that are out of the scope of this discussion).
As I noticed the ecosystem is missing a proper solution to manage versioning and release automation, and being a long-time user of semantic-release which I consider to be powerful, reliable and battle-tested, I decided to start working on a semantic-release plugin (semantic-release-hex) to act as a bridge between those two very different ecosystems (as quickly mentioned in #3065).
I'm planning to use this discussion as a place to share my journey and exchange on the challenges ahead.
After successfully implementing version replacement in the mix.exs (package.json equivalent), writing a comprehensive getting started guide and creating a demo repository, I made a post on the Elixir Forum to introduce semantic-release and semantic-release-hex to the Elixir community, and how they could be used to improve versioning/release workflows.
The post seems to be getting relatively good traction regarding the number of views compared to other posts in the "Libraries" category (based on the time posted and user interaction), which could be an indicator of the project's pertinence.
The latter is particularly exciting (and challenging) because it would eliminate the need for users to have Node.js installed (whether locally or in the CI) and streamline the installation process (not needing to run npm install commands, not maintaining package.json & package-lock.json).
Because this idea could benefit all users of semantic-release, and such an executable should be issued in an official way, my plan is to enhance the semantic-release and semantic-release-cli release workflows by integrating the creation and signing of standalone executables so they get published to the GitHub releases. However, before opening an issue and beginning work on this, I would appreciate your preliminary feedback on the idea. cc @semantic-release/maintainers
I believe this is a good opportunity to make semantic-release a more generic & language-agnostic tool so that other ecosystems can also benefit from its super-powers 🚀
I’m eager to hear your thoughts and discuss that interesting topic with you all!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hey folks,
I've recently made the decision to start evolving towards Elixir as my primary language (for various reasons that are out of the scope of this discussion).
As I noticed the ecosystem is missing a proper solution to manage versioning and release automation, and being a long-time user of
semantic-release
which I consider to be powerful, reliable and battle-tested, I decided to start working on asemantic-release
plugin (semantic-release-hex
) to act as a bridge between those two very different ecosystems (as quickly mentioned in #3065).I'm planning to use this discussion as a place to share my journey and exchange on the challenges ahead.
After successfully implementing version replacement in the
mix.exs
(package.json
equivalent), writing a comprehensive getting started guide and creating a demo repository, I made a post on the Elixir Forum to introducesemantic-release
andsemantic-release-hex
to the Elixir community, and how they could be used to improve versioning/release workflows.The post seems to be getting relatively good traction regarding the number of views compared to other posts in the "Libraries" category (based on the time posted and user interaction), which could be an indicator of the project's pertinence.
I've already received a lot of interesting and constructive feedback from committed forum members, notably to add the ability to update the version in README (as libraries are installed manually in the manifest), but more importantly to distribute
semantic-release
andsemantic-release-hex
as a bundledhex
(NPM equivalent) package.The latter is particularly exciting (and challenging) because it would eliminate the need for users to have Node.js installed (whether locally or in the CI) and streamline the installation process (not needing to run
npm install
commands, not maintainingpackage.json
&package-lock.json
).The best way to do this seems to first build
semantic-release
(and possiblysemantic-release-cli
to also allow bundling asetup
utility) into platform-specific standalone executables, similar to howtailwindcss
does. The code for their standalone CLI build is available in thestandalone-cli/
directory on their main repository.Because this idea could benefit all users of
semantic-release
, and such an executable should be issued in an official way, my plan is to enhance thesemantic-release
andsemantic-release-cli
release workflows by integrating the creation and signing of standalone executables so they get published to the GitHub releases. However, before opening an issue and beginning work on this, I would appreciate your preliminary feedback on the idea. cc @semantic-release/maintainersI believe this is a good opportunity to make
semantic-release
a more generic & language-agnostic tool so that other ecosystems can also benefit from its super-powers 🚀I’m eager to hear your thoughts and discuss that interesting topic with you all!
All the best,
Pierre
Beta Was this translation helpful? Give feedback.
All reactions