This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-20
Channels
- # adventofcode (8)
- # aleph (2)
- # announcements (10)
- # aws (5)
- # aws-lambda (2)
- # babashka (23)
- # beginners (23)
- # biff (9)
- # calva (4)
- # cider (8)
- # clj-kondo (21)
- # clojure (77)
- # clojure-boston (1)
- # clojure-dev (50)
- # clojure-europe (36)
- # clojure-gamedev (3)
- # clojure-nl (1)
- # clojure-norway (3)
- # clojure-spec (33)
- # clojure-uk (3)
- # clojurescript (22)
- # core-async (3)
- # cursive (10)
- # datahike (18)
- # datalevin (1)
- # datascript (9)
- # deps-new (21)
- # emacs (11)
- # events (1)
- # graphql (11)
- # guix (26)
- # java (7)
- # jobs (3)
- # lsp (12)
- # malli (6)
- # pathom (33)
- # pedestal (3)
- # polylith (15)
- # reagent (5)
- # releases (3)
- # remote-jobs (1)
- # scittle (9)
- # sql (27)
- # tools-build (9)
- # vim (7)
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.
@UE21H2HHD 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!
had a go with build.edn @UE21H2HHD... 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 @U0524B4UW. Then you get exactly what you want.
yep @UE21H2HHD, 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
if it preserves structure and comments in deps.edn
when it modifies it then that's even better
I've https://github.com/clj-commons/clj-yaml/blob/a2b0bac30e6b036145e593a8201df7cc730fe36f/deps.edn#L10-L11. Seems to work fine.
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 #C02B5GHQWP4 perhaps?
oops - my mistake @U04V70XH6 - 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)
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 @U04V70XH6 ... 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.