Closed BebeSparkelSparkel closed 2 months ago
I don't understand how this pragma is any better or different than simply changing the version number directly.
Aside from that, I think this is beyond the scope of what I want Gild to do. This type of "bump version" command really belongs in the build tool (like cabal bump major
), or it belongs in a tool specifically meant for changing precise parts of the package description (like some hypothetical cabal-edit version 1.2.3.4
). A principled approach to that requires something like https://github.com/haskell/cabal/issues/7544.
I think you are right that this is out of scope.
Being able to specify how to increment the package version would be useful for ci managing pull requests.
Pragma
increment-version [version-index]
where the optional version index specifies the version number (major, minor, ...) to be incremented. Whencabal-gild
is runIf the version index is not specified and the new
--no-increment-version
flag is not given to thecabal-gild
command, thencabal-gild
should have a non-zero exit. The--no-increment-version
allows the other features of cabal-gild to be run without incrementing the version or having the command fail if no version index is specified.For example with the cabal file
running
the new version would be printed to stdout (shown above)
and the cabal file would be changed to
Solves the issue specifed in https://github.com/snoyberg/mono-traversable/issues/238