deps-new 2023-01-20

has anyone seen/got any build.clj script fragments for lein release type behaviour ? i.e. the sort of version-bumping and git behaviour which can be specified in the lein :release-tasks key - e.g.: https://github.com/mpenet/alia/blob/master/project.clj#L87

Not exactly what you are asking for, but there is https://github.com/liquidz/build.edn

https://github.com/babashka/neil also has some support around version storing and bumping.

@lee build.edn has the version and clojars-deploy stuff and is easily used from build.clj ... and the git stuff is probably easy enough to shell out for, so build.edn might be just the thing - thanks!

It looked interesting to me too, please report back with how it works out for you!

👍 1

had a go with build.edn @lee... it's notion of semver is a bit primitive for my needs - it understands "3.0.0-SNAPSHOT", but not things like "3.0.0-alpha1"

I guess it is not too hard to roll your own thing too @mccraigmccraig. Then you get exactly what you want.

yep @lee, just anxious to avoid writing the code i don't need to 😬

the build.edn idea of keeping your build metadata in its own file seems sound though

Ya neil keeps build info in deps.edn which is also interesting.

if it preserves structure and comments in deps.edn when it modifies it then that's even better

Ya, it uses rewrite-clj, iirc, to bump version in deps.edn, so all is preserved.

👍 1

I probably automate more things than folks typically do for a release, but here's the cl-yaml bb https://github.com/clj-commons/clj-yaml/blob/a2b0bac30e6b036145e593a8201df7cc730fe36f/script/publish.clj#L106-L109.

This doesn't seem related to deps-new - did you mean to post in #tools-build perhaps?

oops - my mistake @seancorfield - that would have been a much better channel

(i did generate my initial deps.edn and build.clj with deps-new ... but clearly i've moved on since then - sorry)

👍🏻 1

FWIW, at work we've taken to tagging releases with, essentially, a date/timestamp rather than actual version numbers, and most of my OSS projects use major.minor.commits -- both of which can be computed easily in build.clj without needing to worry about bumping versions. Even for the OSS projects, the major.minor part is a single line in build.clj and easy to edit when I decide a release warrants a minor version bump (which is fairly rare).

interesting @seancorfield ... major.minor.commits sounds nice and easy ... what do you do about -SNAPSHOT type releases with that scheme ?

major.minor.999-snapshot mostly (until commits gets that high, then 9999-snapshot). Every push to develop on my OSS projects pushes a snapshot build to clojars.