Versioning of in-dev hex packages

Chat / Discussions
1

OK, for the actual released packages it is very simply, just follow semantic versioning and everything is okay, but how to go with the in-dev versions of that package?

Lets assume we have published the package p on hex and its version is a.b.c. The sourcecode is public via github and some people might want to use the version from github. So what should I put in my mix.exs as version after the release?

Shall I leave it as a.b.c-dev since it is the base version with additions (even incompatible ones), or shall I increase any of a, b, c before appending -dev? But then, which one to increase? Maybe I don’t even know beforehand what is going to be the next release.

How do you handle it?

1 Like
2

Does it make sense to use -rc1 then increase the RC number each time? I think anything after - lets Mix know the version is unstable/in-development. You could use that last version section as like a git branch name, but maybe that’s non-standard :wink:

2 Likes
3

This question is not about released packages, but about the development version over there on github (or similar).

And I really can’t update that rc with every single commit :wink:

Also it had the same problem as the described -dev above. Which part of the version number should I bump?

2 Likes