1

I have a (potentially public) development branch for a Haskell project that I also release to Haddock. The head of my release branch always (naturally) has a .cabal file with a version corresponding to the current Haddock version.

But what version should I have in the .cabal file on my development branch? For example, after releasing version 0.1.2.6 on Hackage, no subsequent commit anywhere (esp. along a development branch) is version 0.1.2.6, nor are they (yet) 0.1.2.7. What version should such commits be? Is there a standard practice, either for Hackage in particular, or source control in general (recalling that Cabal imposes restrictions on the values that version can take)?

orome
  • 45,163
  • 57
  • 202
  • 418

1 Answers1

-1

I can't see restrictive rules for version field

The package version number, usually consisting of a sequence of natural numbers separated by dots.

thus - you can use free-form version, and for Git-repos git describe is good choice as an identifier of any changeset, and this data can be inserted into versioned file with smudge|clean filters

Note:

If "only numeric" is a must for you, you can

  • Follow Semantic versioning
  • Use unique (incrementing?) version

but git describe+filter pair become "a must", not "possible" choice

1.0.4-14-g2414721 is converted into (you can, probably, lost unique identification of changeset in case of branchpoint inbeetwen, but...) 1.0.4.14 and such version will be:

  • correct for you
  • usable for identification of originating changeset
  • easily obtained (automatically) from git describe
Community
  • 1
  • 1
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • Sorry, I wasn't clear what I meant my "restrictive": it has to be a number — i.e., it can't be something obviously descriptive like `0.1.2.6++` or `0.1.2.6->7dev`. I suppose I could just use `0.0.0.0`, but the question is really about whether there is a standard practice, esp. on *Hackage*. – orome Sep 29 '15 at 12:07
  • @raxacoricofallapatorius - "Standard practice" is widely-accepted [Semantic versioning](http://semver.org/). You can adopt it to your needs – Lazy Badger Sep 29 '15 at 12:37
  • The question is about what valid value to provide in `.cabal` between Hacakge releases on a development branch. It can't be any past or future Hackae release version, and it must be "a sequence of natural numbers separated by dots". I've always used semantic version internally, and that's really part of the question: how do people "adapt it to" *Hacakge*. (This answer seems to be ignoring that context.) – orome Sep 29 '15 at 13:04
  • @raxacoricofallapatorius - isn't "1.0.4 - 1.0.4.1 - 1.0.4.2 - ... - 1.0.5" line OK for you? – Lazy Badger Sep 29 '15 at 13:12
  • Given that I have, say `0.1.2.6`, for example, and that the next Hackage release will be `0.1.2.7`, how should I number interim versions in my `.cabal`? Remember that this must build, and must install (with `cabal install`) for people who download the development branch. – orome Sep 29 '15 at 15:26
  • @raxacoricofallapatorius - `0.1.2.6.*` (note - I know nothing about possible additional build-install limitations) – Lazy Badger Sep 29 '15 at 15:42
  • "I know nothing about possible additional build-install limitations" — but *that's the question*! – orome Sep 29 '15 at 15:45
  • I've removed the tags that were confusing. – orome Sep 29 '15 at 15:58