I suspect quite a few Travis-enabled Clojure projects do full multi-version testing – but it’s hard to tell at a glance from Travis’s logs. For example, both HoneySQL and clj-time perform multi-version testing on Travis, but they do it through Leiningen aliases so there’s only one “build” – no grid of Clojure versions. I’d be interested in hearing of techniques to surface a grid of Clojure versions being tested on Travis.
Note that clj-time is tested against a grid of JVM versions and that does surface on Travis – and I’ve just noticed that testing against Clojure master on OpenJDK 7 fails, presumably because Clojure master now requires Java 8? (but the Oracle JDK 7 build on Travis doesn’t fail). Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ________________________________ From: clojure@googlegroups.com <clojure@googlegroups.com> on behalf of Nathan Fisher <nfis...@junctionbox.ca> Sent: Friday, July 27, 2018 4:11:05 PM To: clojure@googlegroups.com Subject: Rusts Upgrades Hi Folks, Reading up the recent blog post “What is Rust 2018” and happened upon this; “We put in a lot of work to make upgrades painless; for example, we run a tool (called “crater”) before each Rust release that downloads every package on crates.io<http://crates.io> and attempts to build their code and run their tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html Seems an interesting idea and with Travis and other CI services providing free builds for OSS it doesn’t need to put a heavy financial/operational burden on a single entity. The main benefit for this is for people could get a quick centralised overview of compatibility of various projects and impending releases of Clojure. The main idea would be to have a grid view of the latest Clojure projects and their status against HEAD of Clojure (are snapshots pushed to a maven repo automatically as a result of a commit build?). Travis allows periodic builds so that could be used to trigger verification even when changes haven’t occurred. In terms of initial focus targeting the top-N projects on Github makes the most sense to me. The bit I’m still thinking through is providing some form of dashboard/aggregation without requiring a large investment in changes, infrastructure, etc. Might fit in nicely with something like clojars? Was thinking initially having a Github page with a table of projects and their build badges and talking to maintainers about configuring periodic builds with the latest Clojure snapshot. Thoughts? Cheers, Nathan -- - sent from my mobile -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com<mailto:clojure+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
