Open lread opened 1 year ago
Hi, I think that'd be a good idea. We could set up bb script to tag as part of the deploy.
Agreed, that sounds helpful for many reasons. Since we have multiple versions and deploys in a single repo, we could do something such as the tauri project does and tag the version with the package name + version, e.g. kit-generator 0.1.7
.
Cool! Related, but could be treated as a separate issue, is including scm
info in the pom
s of released jars. This allows tools like clojars and cljdoc to point back the sources (and articles) for a release.
That's a good call as well, and I think makes sense to keep it all part of the same issue.
Agreed, that sounds helpful for many reasons. Since we have multiple versions and deploys in a single repo, we could do something such as the tauri project does and tag the version with the package name + version, e.g.
kit-generator 0.1.7
.
Do we actually have a use case where we need to have different version for kit libraries? I don't see a use case where someone will update one library but not the other. Since they are all used together in a kit project, it may as well make sense for all of them to have the same version and the same tag.
Hiya! I noticed that kit is using rewrite-clj.
Rewrite-clj runs the tests of libraries that use it against rewrite-clj main branch. This helps me to discover when a change I make to rewrite-clj might break some existing lib that uses it. To stay sane, I only run against the latest released version of libs.
If you were to start version tagging the kit GitHub repo when releasing kit, I could add it to the rewrite-clj suite. I think kit-generator is the lib of interest for rewrite-clj, ya?
If this is not interesting to you, that's totally fine too. Lemme know.