I don't see why not. Our commit volume and artifact size are modest enough I can't imagine it'd put undue strain on asf infra.
On Wed, Jul 29, 2026, at 10:52 AM, Shailaja Koppu wrote: > Hi Josh, > > The idea of snapshot build sounds good. Can we do the same for Sidecar as > well, so we can progress with snapshot artifacts of Sidecar when needed? > > Thanks, > Shailaja > > >> On Jul 28, 2026, at 2:44 AM, Josh McKenzie <[email protected]> wrote: >> >> *Current problem:* >> • cassandra-sidecar builds off a specific released artifact from >> cassandra-analytics. This is a byproduct of us needing a voted upon and >> released artifact of analytics to build a release of sidecar off of as per >> ASF rules / legalities. >> • This means if you have changes that touch both projects (which many do), >> you have to: >> • Commit to analytics >> • Cut an analytics release (CI, VOTE, time frame, etc) >> • Then merge your changes into sidecar bumping the analytics dependency >> • This is Clearly Bad. >> >> I'd like to propose a temporary solution to this while we work through >> CEP-63 (which includes cutting releases for the two projects together): >> 1. Change the cassandra-analytics subproject to publish a SNAPSHOT build on >> every commit >> 2. Change sidecar to build off those SNAPSHOT builds for day-to-day work >> (can basically bump that artifact ref whenever we want or need to >> sidecar-side on trunk) >> 3. When it's time for a cassandra-sidecar release, we >> 1. go through formal release verification on analytics, test, vote, >> release, then >> 2. point sidecar to that released artifact and go through release >> verification, test, vote, release. >> This will allow us to stage and merge patches to both repos w/out having >> that formal vote and release analytics dependency gumming up the works and >> slowing things down. >> >> So: any concerns? >> >> ~Josh
