Zach Daniel

Yeah, definitely some interesting issues here, especially considering that `uniq_list_of/2` is really just filtering a generator. So for some context here, what I'm doing is adding `StreamData` generators that produce...

I would really love to see this solved.

I think a behaviour like the following would be the cleanest: ``` defmodule GitOps.VersionStorage do @callback read_version() :: {:ok, String.t()} | {:error, String.t()} @callback write_version() :: {:ok, String.t()} | {:error,...

You can reference a module anywhere, but I wouldn't do it there. We'd provide one called `GitOps.VersionStorage.MixModuleAttribute`, and one called `GitOps.VersionStorage.File`. They would put it in their application config which...

Nothing *explicitly* was done for this, but I have just recently pushed an addition (but not released it yet, because its untested and I still want to try it out)...

Ultimately I'd be fine with standardizing the way you've mentioned, but it would involve a major release and/or it would need to be non-default behavior because I wouldn't want to...

Yeah, there really isn't any good way to manage this with the current design of git_ops. It uses git tags to determine previous versions, and things like that. So you...

Its a fair amount of work, though, and I don't really plan on doing it anytime soon.

Agreed. Overall I doubt the juice is worth the squeeze, but git submodules could definitely be a solution, along with the umbrella release task. I'd happily review a PR to...

Hello! Originally the design for this was for manual usage, so if you wanted to build a release but nothing would warrant a release, it should stop and tell you....