Honestly, I do not see any reason to produce `leftpad`-like packages :) Besides this functionality, the package contains barely anything (besides few wrapped `:os.cmd` calls.) You are to use in :dev ⇒ include the package and build your own task on top of it. hex part won’t hurt your code much.
-- AM On Tuesday, October 11, 2016 at 5:41:50 PM UTC+2, John Hamelink wrote: > > Indeed! > > Would you consider a PR where I extract the leaves/sprouts and git pushing > functionality into a separate package, so that I could then build a mix > task for my purposes? > > JH > -- > John Hamelink > Sent with Airmail > > On 11 October 2016 at 16:38:30, Aleksei Matiushkin ( > [email protected] <javascript:>) wrote: > > Hey John, > > Allen is right, it’s about publishing to `hex`, but you might want to > adopt version suggestion code ( > https://hexdocs.pm/issuer/Issuer.Utils.html#sprouts/1) > > -- > AM > > On Tue, Oct 11, 2016 at 5:33 PM, Allen Madsen <[email protected] > <javascript:>> wrote: > >> 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] >> <javascript:>> 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] <javascript:>. >> > 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 a topic in the >> Google Groups "elixir-lang-core" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/elixir-lang-core/MMB3ru8Rcxc/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> 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. >> > > > > -- > > *Aleksei* > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/MMB3ru8Rcxc/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGF5_6fqADOn-a2R%2BCvusag_%2BHM5xq8X1atUtad5SRkdX7_rhQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGF5_6fqADOn-a2R%2BCvusag_%2BHM5xq8X1atUtad5SRkdX7_rhQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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/5ccaa880-8f74-48bc-aa15-a86d048210ae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
