WIP: Add support for versioning multiple subprojects

[eliaslevy]

Do to so the settings are moved from the build to each project via using projectSettings instead of buildSettings and adding a new per project setting dynverTagPrefix to configure the project version tag prefix.

If these changes look acceptable, than I can update the PR to modify the docs and default the prefix to the project name.

---

This change is 

[dwijnand]

This means that git describe is run for each project, and that builds in which each project share the same version (which I'd guess is a vast majority of builds) you can no longer define/redefine/override things in ThisBuild scope..

I'm not sure about the cost/benefit of this. Let me sit on this for a while.

[eliaslevy]

That's correct. That said, git describe is pretty fast. I can't imagine that being the limiting factor on build time.

As for no longer using ThisBuild, the sbt docs suggest that build level setting should be limited mostly to simple value assignments, since settings don't exhibit dynamic dispatch behavior.

In regards to overriding settings in a single place, that can still be accomplished by using the common settings pattern described in the sbt docs.

[dwijnand]

You're right in what you state. But for more context that "should be limited mostly to simple value assignments, since settings don't exhibit dynamic dispatch behavior" was added more or less in response to my frustration to sbt's fundamental limitation, aka sbt/sbt#2899.

Put differently I think the common settings pattern shouldn't be necessary: you shouldn't need to define the same 400 settings on each of your 3-30 projects.. That's what the scope hierarchy should've taken care of.

[eliaslevy]

I agree. The current sbt setting semantics are confusing to common users and frustrating in general.

[dwijnand]

Here's an idea: can leave things defined in build scope, and then re-define some (as little as possible) settings in project scope that invoke git if the dynverTagPrefix in that project that differs from dynverTagPrefix in ThisBuild, otherwise fall back on the default build scope value.

This is to allow things to (continue to) be re-definable in build scope, limit the default number of invocations of git to 1, but allow this support.

[eliaslevy]

How would you do that? Any references in a setting in build scope to other settings are automatically scoped to the build scope. As you state in the sbt issue, settings do not have dynamic dispatch semantics.

dynverTagPrefix has to be defined per project. That means dynverInstance has to be defined per project, as it depends on dynverTagPrefix dynverGitDescribeOutput and dynver depends on dynverInstance, so they must be defined in project scope. That means pretty much everything else must be defined in the project scope. AFAIK the only thing that could be defined in build scope is dynverCurrentDate.

[dwijnand]

How would you do that? Any references in a setting in build scope to other settings are automatically scoped to the build scope.

I meant the other way: make project-scoped settings depend on build-scoped settings.

But I would have to experiment to see how exactly to do it. Have a good, if not I'll try to get to it.

[dwijnand]

I didn't get to it.

This is now stale, with a merge conflict on src/main/scala/sbtdynver/DynVerPlugin.scala, so I'll close it for now.

But if we can sort this change out, we could try reviewing it again together.

[LeifW]

Would appreciate having a way to give our subprojects different versions. Having dynverTagPrefix requiring a ThisBuild scope seems to be preventing this.
We already use "common settings" and / or plugins for stuff we want to share between multiple projects.