├── .formatter.exs ├── .gitignore ├── .iex.exs ├── LICENSE.md ├── README.md ├── config └── config.exs ├── lib ├── mix │ └── tasks │ │ ├── bin │ │ ├── db.ex │ │ ├── ff.ex │ │ └── release.ex │ │ ├── current.ex │ │ ├── githooks │ │ ├── deploy.ex │ │ └── hexup.ex │ │ ├── inc.ex │ │ ├── is_release.ex │ │ ├── last_commit.ex │ │ ├── major.ex │ │ ├── minor.ex │ │ ├── name.ex │ │ ├── next.ex │ │ ├── patch.ex │ │ ├── release │ │ └── bin.ex │ │ ├── tag.ex │ │ ├── untag.ex │ │ ├── up.ex │ │ └── version.ex ├── version_tasks.ex └── version_tasks │ ├── fn_expr.ex │ └── shell.ex ├── mix.exs ├── mix.lock └── test ├── tasks ├── major_test.exs ├── minor_test.exs ├── name_test.exs └── patch_test.exs ├── test_helper.exs └── version_tasks_test.exs /.formatter.exs: -------------------------------------------------------------------------------- 1 | [ 2 | inputs: ["mix.exs", "{config,lib,test}/**/*.{ex,exs}"] 3 | ] -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # The directory Mix will write compiled artifacts to. 2 | /_build 3 | 4 | # If you run "mix test --cover", coverage assets end up here. 5 | /cover 6 | 7 | # The directory Mix downloads your dependencies sources to. 8 | /deps 9 | 10 | # Where 3rd-party dependencies like ExDoc output generated docs. 11 | /doc 12 | 13 | # Ignore .fetch files in case you like to edit your project deps locally. 14 | /.fetch 15 | 16 | # If the VM crashes, it generates a dump, let's ignore it too. 17 | erl_crash.dump 18 | 19 | # Also ignore archive artifacts (built via "mix archive.build"). 20 | *.ez 21 | 22 | # Code generated from task during testing 23 | /bin 24 | /lib/version_tasks/release.ex 25 | rel/commands 26 | -------------------------------------------------------------------------------- /.iex.exs: -------------------------------------------------------------------------------- 1 | alias Mix.Tasks.Version.{Current,Next} 2 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # MIT License 2 | 3 | Copyright (c) 2017 Andrew Forward 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining 6 | a copy of this software and associated documentation files (the 7 | "Software"), to deal in the Software without restriction, including 8 | without limitation the rights to use, copy, modify, merge, publish, 9 | distribute, sublicense, and/or sell copies of the Software, and to 10 | permit persons to whom the Software is furnished to do so, subject to 11 | the following conditions: 12 | 13 | The above copyright notice and this permission notice shall be 14 | included in all copies or substantial portions of the Software. 15 | 16 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 17 | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 18 | MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND 19 | NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE 20 | LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION 21 | OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION 22 | WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 23 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # VersionTasks 2 | 3 | Provides an opinionated, but rational, set of mix tools for managing 4 | version numbers for your Elixir project using the following scheme. 5 | 6 | ``` 7 | Major.Minor.Patch 8 | ``` 9 | 10 | You decide what each version number means, whether it's [semantic 11 | versionning](http://semver.org/), [Spec-ulation from Rich Hickey](https://www.youtube.com/watch?v=oyLBGkS5ICk), or any other scheme. 12 | 13 | ## Installation 14 | 15 | ```elixir 16 | @deps [ 17 | {:version_tasks, "~> 0.12.0"} 18 | ] 19 | ``` 20 | 21 | ## Usage 22 | 23 | A set of Mix Tasks for managing your version numbers. This is best used 24 | in conjunction with your release strategy, and so we also provide some 25 | opionated generated code / bash scripts to support you in your quest for 26 | towards continuous deployment. 27 | 28 | To get a list of all available mix tasks (in case the docs might be stale), 29 | you can run 30 | 31 | mix version 32 | 33 | Below is a bit more information about the available tasks and how to use them. 34 | 35 | ### Information Tasks 36 | 37 | The following tasks just report back information about your project 38 | without actually changing it. 39 | 40 | Here's the basic usage 41 | 42 | MIX_QUIET=1 mix version. 43 | 44 | Notice the MIX_QUIET=1, can sometimes be important if you are 45 | using this within a `dev` environment where additional debugging 46 | output might be included 47 | 48 | The examples below will omit the `MIX_QUIET=1`for brevity, and as 49 | it isn't strictly required. 50 | 51 | #### mix version.current 52 | 53 | To retrieve the current version of your application, run 54 | 55 | mix version.current 56 | 57 | The call back returns the current version of your project, for example 58 | 59 | 1.2.3 60 | 61 | This is based on your mix.exs file. 62 | 63 | #### mix version.next 64 | 65 | To retrieve the _next_ version of your application, run 66 | 67 | mix version.next ? 68 | 69 | The default increment step is patch, here are a few examples from the version above 70 | 71 | mix version.next 72 | 1.2.4 73 | 74 | mix version.next patch 75 | 1.2.4 76 | 77 | mix version.next minor 78 | 1.3.0 79 | 80 | mix version.next major 81 | 2.0.0 82 | 83 | #### mix version.name 84 | 85 | After an upgrade, you might want to trigger additional actions, such as run tests 86 | create a release and deploy an update. You can ask for the `name` of the version using: 87 | 88 | # For anything like X.0.0, that's a major release 89 | mix version.name 90 | major 91 | 92 | # For anything like X.Y.0, that's a minor release 93 | mix version.name 94 | minor 95 | 96 | # For all other releases, like X.Y.Z, that's a patch release 97 | mix version.name 98 | patch 99 | 100 | #### mix version.is_release 101 | 102 | This is the same as `mix version.name` with the exception that it will only return the 103 | version name *IF* the last commit was a version commit, which looks like `vX.Y.Z`. 104 | 105 | # If the last commit was `Doing something great`, then it returns nothing 106 | mix version.is_release 107 | 108 | # However, if the last commit was `v1.2.0`, then it returns `minor` 109 | mix version.is_release 110 | minor 111 | 112 | #### mix version.last_commit 113 | 114 | To help us trigger when a release has been requested, we are exposing the last commit 115 | message, this delegates to git and simply calls (`git log --format=%B -n 1 HEAD`) 116 | 117 | # Grab the last commit 118 | mix version.last_commit 119 | Simplify the database backup, to make restore easier 120 | 121 | # Hey, this commmit looks like a new release was commit 122 | mix version.last_commit 123 | v1.4.5 124 | 125 | 126 | #### mix version.(major|minor|patch) 127 | 128 | You can also expose just the major number, or minor number or patch number. 129 | This would be useful for scriping where you wanted to join the numbers with 130 | a dash, and your `bash` is not up to the par, so you call it out individually. 131 | 132 | # Let's assume `mix version.current` is 1.2.3 133 | mix version.major 134 | 1 135 | 136 | mix version.minor 137 | 2 138 | 139 | mix version.patch 140 | 3 141 | 142 | ### Local Editing Tasks 143 | 144 | The following tasks will edit your local files, but will not commit or push any of those changes. 145 | 146 | #### mix version.inc 147 | 148 | Increment your project to the next version, this will update your mix.exs AND your README.md file. 149 | 150 | mix version.inc ? 151 | 152 | Your `mix.exs` MUST HAVE a variable named as follows for this to work 153 | 154 | @version "1.2.3" 155 | 156 | This is the default is based on a template from [Dave Thomas](https://pragdave.me/) with his `mix gen