I'd like to put forward my usecase for this sort of functionality. At my company, we build debian packages from our releases using my module - ExrmDeb <https://github.com/johnhamelink/exrm_deb> - with Jenkins. When a git push is made to master, this triggers a build which is then deployed onto our staging environment. We've currently implemented the auto-versioning functionality in bash scripts, which I don't particularly like as they are not as smart and fully featured as they could/should be.
One of the most annoying edge-cases is when 2 commits which would trigger a package build happen in quick succession, and one job doesn't know about the other so they both try to mark themselves as the same version and one of them fails. When we're in staging, we don't care about semver - we manually review the changes between staging and production and make sure our production versions conform to semver as part of the production release process. Aleksei, I'll give your package a go :) JH On Monday, October 10, 2016 at 12:26:15 PM UTC+1, Aleksei Matiushkin wrote: > > Hi again, > > I have the functionality discussed in this topic implemented. > > https://github.com/am-kantox/issuer > > Please note, this is a [fully functional] prove of concept. It adds `mix > issuer` task to `mix`. This task does the following steps: > > — runs `mix test` > — loads the list of existing tags from remote repo and gives the lists > of suggestions (https://hexdocs.pm/issuer/Issuer.Utils.html#sprouts/1) > for what version we are to bump > — updates the version in both `config/VERSION` and `README.md` > — git commit -am ':paperclip: Bump version #{version}.' && git push && git > tag version && git push --tags > — hex publish > > The above is done in the safest manner I could imagine. I am open to > suggestions, ideas, swearing, cursing, profanity. I have already switched > to using `issuer` for publishing in a) `issuer` itself and another package > I am maintaining. > > Thanks for your attention. > > On Friday, September 30, 2016 at 4:59:00 PM UTC+2, José Valim wrote: >> >> Even with moving the version to a file, it still feels like it is more >> trouble than it is worth. Not all version bumps are the same. I may want to: >> >> 1. Bump major >> 2. Bump minor >> 3. Bump tiny >> 4. Bump to any of the above and add a -dev suffix >> 5. Bump from -dev to -rc >> 6. Bump from -rc.x to -rc.x+1 >> >> And there is one very easy way to do this: open up the file where the >> version is written, be it mix.exs or a separate file, and just change the >> version. Of the whole release process, bumping the version is the *hardest* >> part to automate because one API that considers all cases above will be >> much harder to use than doing the change yourself. >> >> Here are all saner and simpler to use alternatives: >> >> 1. Pass the version explicitly. Pros: it is explicit and you can check >> the new version is more recent than the current one. Cons: you still need >> to parse the file where the version is listed. >> >> mix publish 0.5.0 >> >> >> 2. Assume the version has already been changed and committed. Pros: IMO >> that's the sanest approach because there are other things I need to do when >> publishing a package besides bumping the version, such as versioning the >> CHANGELOG and adding dates. You could still have a "mix publish" command >> that would read the version and do the rest of the work: >> >> >> git tag v0.5.0 >> >> git push --tags >> >> mix hex.publish >> >> >> Even though, don't expect such to be added to Elixir. It does too little >> and is too opinionated. >> >> *José Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Director of R&D >> >> -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/06c77da7-3268-4bd2-bcb3-9abfa97d4890%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
