Hey John, Aleksei's package is for automating package releases to hex rather than application releases for deployment. Allen Madsen http://www.allenmadsen.com
On Tue, Oct 11, 2016 at 11:20 AM, John Hamelink <[email protected]> wrote: > 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 - 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. -- 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/CAK-y3Cv%3D2S0UediwXKHCqcYcFkXx-%2B-s8pPhnDj0xeCvqc%2BRTA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
