Add  mix release  task similar to  rake  release

451 views
Skip to first unread message

Alexsei Matiushkin

unread,
Sep 21, 2016, 7:17:38 AM9/21/16
to elixir-lang-core
It would be handy to have a mix task, similar to what rake release does in the ruby world https://github.com/bundler/bundler/blob/master/lib/bundler/gem_helper.rb#L55 :
  • mix.compile
  • mix test
  • source control commit with tag=CURRENT_VERSION
  • mix hex.publish
Everything save for the third item in this list might be easily done with shell alias/function, but this beast in the middle literally screws me up: sometimes I forget to push a tag, sometimes I forget to update a version, etc. It would be really great to implement the functionality that tries tests, reads a version from mix.exs, uses it as a tag in commit, publishes to hex.pm if everything above succeeded.

I could put some effort in implementing this, but I really need kinda feedback on whether it’s needed and—if so—some guidance on how to approach it.

Rgds, AM-73

Louis Pilfold

unread,
Sep 21, 2016, 7:20:06 AM9/21/16
to elixir-l...@googlegroups.com
Heya

I'm not a fan of this as everyone will have a different steps in their
release process.

Personally I would just write a little shell script (or mix task) to do this.

Cheers,
Louis

On 21 September 2016 at 12:17, Alexsei Matiushkin
> --
> 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 elixir-lang-co...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/0095086f-2c3d-4dce-9263-c71e72151486%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Alexsei Matiushkin

unread,
Sep 21, 2016, 7:29:48 AM9/21/16
to elixir-l...@googlegroups.com
For hex publishing, this process is more or less the same and it’s implicitly proven by `rake release` existence. I have no problem writing shell function, but in my opinion, mix task here is more appropriate since it has a direct access to the version and in shell I would parse `mix.exs` which is a bit ugly.

Anyway, I got your reasoning, thx for reaching out.

--
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM-pwt5DQCck2G6G9B%3D7EMMBOs%3D0rnjjxHcBv%3D9gqXQZ_ynagw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--

Alexsei MatiushkinSoftware Engineer - R&D
 
Office    (+34) 935 679 834
 

6 Bevis Marks, London, EC3A 7BA, United Kingdom
Torre Mapfre, Planta 10, Marina, 16-18, 08005 Barcelona, Spain
 
LinkedIn    Twitter    YouTube
 
Kantox Limited is registered in England and Wales as a Limited Company: No 07657495 and is authorised by the Financial Conduct Authority, FRN: 580343, as a Payments Institution under the Payment Services Regulations 2009. This email is subject to professional secrecy. It is confidential and for the exclusive use of its addressee. If you are not the addressee, you are not authorised to read, keep or disseminate it.

Allen Madsen

unread,
Sep 21, 2016, 7:48:54 AM9/21/16
to elixir-l...@googlegroups.com
I agree with Alexsei that it is pretty standard. If you want to do something off the beaten path, you still have that option with the individual commands available.

Ben Wilson

unread,
Sep 21, 2016, 8:21:53 AM9/21/16
to elixir-lang-core, allen.c...@gmail.com
Problematically, Elixir already has a notion of what a "release" (http://erlang.org/doc/design_principles/release_structure.html) is and it has nothing to do with hex. We probably do not want to overload that term.

mix hex.publish is also already a thing, so we'd need some other name here.
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 elixir-lang-co...@googlegroups.com.



--

Alexsei MatiushkinSoftware Engineer - R&D
 
Office    (+34) 935 679 834
 

6 Bevis Marks, London, EC3A 7BA, United Kingdom
Torre Mapfre, Planta 10, Marina, 16-18, 08005 Barcelona, Spain
 
LinkedIn    Twitter    YouTube
 
Kantox Limited is registered in England and Wales as a Limited Company: No 07657495 and is authorised by the Financial Conduct Authority, FRN: 580343, as a Payments Institution under the Payment Services Regulations 2009. This email is subject to professional secrecy. It is confidential and for the exclusive use of its addressee. If you are not the addressee, you are not authorised to read, keep or disseminate it.

--
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 elixir-lang-co...@googlegroups.com.

Alexsei Matiushkin

unread,
Sep 21, 2016, 8:25:16 AM9/21/16
to elixir-l...@googlegroups.com
Indeed, but the name is likely not a problem. 
•  mix   release
•  mix  tag.publish
•  mix  full.publish

whatever. The question is whether this task is really needed.

To unsubscribe from this group and all its topics, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6e0f7ab2-db66-432c-b5e2-b1c150591c52%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Jaap Frolich

unread,
Sep 29, 2016, 5:34:14 AM9/29/16
to elixir-lang-core
I agree this would be a very nice feature to have. It would be even nicer if it automatically bumps up the version number, and perhaps a command line argument to do a major release.

Cheers,

Jaap
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.

Eric E.

unread,
Sep 29, 2016, 12:34:20 PM9/29/16
to elixir-lang-core
Unfortunately, it is not as simple as you might think to "bump the version number," as mix.exs is any arbitrary Elixir code. There is no way to safely modify it programmatically.

-1 on this, as everyone may have different versions or release processes and I don't think it's worth the maintenance burden in Elixir Core. I welcome it as a hex package, however, since there is nothing here AFAIK that requires it to be implemented in core.

Jaap Frolich

unread,
Sep 30, 2016, 1:07:49 AM9/30/16
to elixir-lang-core
Why is there no way to modify it programmatically? We can do a pretty good regex probably, but maybe even better is to do a ast-transformation of some kind? Why do you think it is impossible.

What I really liked about elixir, is that publishing a package is so simple out of the box, with no additional packages needed.

Updating version number is fairly trivial, as I think almost all of the community is striving to adhere to semver. And bumping version number tagging it etc. is quite repetitive and prone to error. That's why we have computers! ;)

Cheers,

Jaap

OvermindDL1

unread,
Sep 30, 2016, 10:10:31 AM9/30/16
to elixir-lang-core
Just a side note on a similar but related topic, the way Elm does releases is *awesome*.  Package starts at 1.0.0, that is mandated by the package system.  It scans the public interface of the package when you publish or call 'elm bump' or whatever the command was and changes the version as appropriate, either by the patch number if no interface change, the middle number if only additions, or the major number if there are backwards incompatible changes.  It will not catch logic changes of course but you can force a higher bump as well.  This is pretty great package management and lets you know when you did something that changed a higher number than you wanted.  It would be nice to have such a feature here as well although I am unsure how feasible that is.

Eric Entin

unread,
Sep 30, 2016, 10:14:35 AM9/30/16
to elixir-lang-core
Ok, what about code like this:

version: version()
...
defp version do
  "0.0.1"
end

or like this:

version: File.read!("VERSION")

as you might imagine from these examples, a regex or an AST transformation will never be able to handle several common cases such as these.

Aleksei Matiushkin

unread,
Sep 30, 2016, 10:28:06 AM9/30/16
to elixir-l...@googlegroups.com
I would explicitly claim the version is to be stored in `project_root/VERSION` file (and loaded from `mix.exs` with `version: File.read!("VERSION")`) and the task is to try to read this `VERSION` file and gracefully reject to complete on fail, printing a friendly message like “Please extract the version number into VERSION file.”

To unsubscribe from this group and all its topics, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/c77971a2-808a-493e-a987-5aae5aa6f4d4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

José Valim

unread,
Sep 30, 2016, 10:59:00 AM9/30/16
to elixir-l...@googlegroups.com
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
Skype: jv.ptec
Founder and Director of R&D

Aleksei Matiushkin

unread,
Oct 10, 2016, 7:26:15 AM10/10/16
to elixir-lang-core, jose....@plataformatec.com.br
Hi again,

I have the functionality discussed in this topic implemented.


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.

John Hamelink

unread,
Oct 11, 2016, 11:20:52 AM10/11/16
to elixir-lang-core, jose....@plataformatec.com.br
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

Allen Madsen

unread,
Oct 11, 2016, 11:33:39 AM10/11/16
to elixir-l...@googlegroups.com, jose....@plataformatec.com.br
Hey John, Aleksei's package is for automating package releases to hex
rather than application releases for deployment.
Allen Madsen
http://www.allenmadsen.com
> --
> 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 elixir-lang-co...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/06c77da7-3268-4bd2-bcb3-9abfa97d4890%40googlegroups.com.

Aleksei Matiushkin

unread,
Oct 11, 2016, 11:38:30 AM10/11/16
to elixir-l...@googlegroups.com
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

--

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 elixir-lang-core+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

Aleksei

John Hamelink

unread,
Oct 11, 2016, 11:41:50 AM10/11/16
to elixir-l...@googlegroups.com, Aleksei Matiushkin
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
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.
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.

Aleksei Matiushkin

unread,
Oct 11, 2016, 11:47:11 AM10/11/16
to elixir-lang-core, aleksei.m...@kantox.com
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
AM

> email to elixir-lang-co...@googlegroups.com.
> 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 elixir-lang-co...@googlegroups.com.



--

Aleksei

Reply all
Reply to author
Forward
0 new messages