Giters

sbt / sbt-dynver

An sbt plugin to dynamically set your version from git

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Customize the tag name format?

swsnr opened this issue · comments

commented

A repo I'm working tags its releases as projectname-X.Y.Z and for the sake of consistency with historic tags and other repos in the org I'd rather not like to change the tag format.

Unfortunately, though, sbt-dynver only considers tags named like vX.Y.Z, and this format seems to be baked in rather deep, so I'm not sure how change it, or if it's even possible to change this short of changing sbt-dynver itself?

commented

I'd have to check, but I'd be happy if this were an option.

commented

@dwijnand So it's not possible currently?

commented

No. Or: not yet 😉

commented

@dwijnand Are you luring me into making a pull request? 😉

commented

@dwijnand I looked at the code, but it hardcodes the prefix v all over the code, and the way from SBT settings to git describe and back again is rather indirect. Making the prefix customisable turned out to be not as simple as I had hoped :sad:

I must admit that I found it a quicker solution to implement a minimal wrapper around git describe myself for the project to get the build done.

I'll perhaps take a look again at some point, but please don't expect anything from me any time soon.

I'm sorry.

commented

@dwijnand That said, I stumbled over a few things while looking through the code and wondered whether you could perhaps answer a few questions 😊

  1. In a few places objects inherit from functions, eg, object GitDirtySuffix extends (String => GitDirtySuffix). I must admit that I've never seen this before 😲; what's behind this trick?
  2. In one place the companion object inherits from its companion case class: object DynVer extends DynVer(None). I presume that is to make the companion object behave as the "empty" instance of the case class at the same time? Like object DynVer { val empty = DynVer(None) } but right in the companion object?
  3. Last, but not least, I see that all settings are in buildSettings, which I understand because there's just one single way to parse the git describe output right now. But if the prefix was customisable, wouldn't it make sense to move everything to projectSettings, to allow different tags for different sub-projects and thus make different sub-projects have their own versions, eg, in a large mono repo containing many independent projects?
commented

I'll perhaps take a look again at some point, but please don't expect anything from me any time soon.

I'm sorry.

No worries 😄

In a few places objects inherit from functions, eg, object GitDirtySuffix extends (String => GitDirtySuffix). I must admit that I've never seen this before 😲; what's behind this trick?

Those objects are case class companion objects. When you don't declare the companion object they're synthesised to extend (if memory serves) scala.runtime.AbstractFunctionX, at a later point I declared the companion object, and for (partial) backwards compatibility I made them extends scala.FunctionX. So the trick is they extend function, and their apply methods are generated by the compiler, due to them being companions of the case class (they're synthetic apply methods).

In one place the companion object inherits from its companion case class: object DynVer extends DynVer(None). I presume that is to make the companion object behave as the "empty" instance of the case class at the same time? Like object DynVer { val empty = DynVer(None) } but right in the companion object?

That's right. The reason (IIRC) is backwards compatibility again. I used to be just a singleton object with a function, later it become a class with a class parameter and a class method, so I retrofitted the singleton object (now companion object).

Last, but not least, I see that all settings are in buildSettings, which I understand because there's just one single way to parse the git describe output right now. But if the prefix was customisable, wouldn't it make sense to move everything to projectSettings, to allow different tags for different sub-projects and thus make different sub-projects have their own versions, eg, in a large mono repo containing many independent projects?

Yeah, that would probably have to be handled. See the discussion in #62.

I'll close this ticket, I guess. We can always open a new one if there's renewed interest.

commented

@dwijnand Thanks for taking the time to explain and for your understanding! ❤️

commented

Support for this was added with #158.