> Josh, bundling releases gets tricky in that you need to include the library > sources, because the cassandra release is essentially being voted on (because > it has been built) with non-released dependencies. Arguably, one shouldn't vote on a release of Accord unless there's something that's integrated it and shown it's working. Through that lens it doesn't make sense to release those dependencies w/out the parent, nor the parent without the dependency.
Not a hill I'm willing to die on but at least out of the gate, seems like a way we could streamline the process of cutting releases until someone / something external starts exerting influence on Accord. On Tue, Jan 17, 2023, at 4:39 PM, Mick Semb Wever wrote: >> Regarding the use of snapshots, this isn’t impossible Henrik - I floated >> this as an option. But besides the additional overhead during development, >> this does not maintain reproducible builds, as the snapshot can change. > > > You would reference the snapshot dependency by the timestamped snapshot. This > makes it a reproducible build. > > We have done this with dtest-api already, and there's already a comment > explaining it: > https://github.com/apache/cassandra/blob/trunk/.build/build-resolver.xml#L59-L60 > > > It introduces some overhead when bisecting to go from the snapshot's > timestamp to the other repo's SHA (this is easily solvable by putting the SHA > inside the jarfile). > > I don't see the problem of letting trunk use snapshots during the annual > development cycle, if we accept the overhead of cutting all library releases > before we cut the first alpha/beta. > > FTR, i'm sitting on the fence between this and submodules. There's many dev > tasks we do, and different approaches have different pain points. The amount > of dev happening in the library also matters. I also agree with Derek that > linking in the source code into in-tree is a significant thing to do, just to > avoid the rigamaroles of dependency management. > > Josh, bundling releases gets tricky in that you need to include the library > sources, because the cassandra release is essentially being voted on (because > it has been built) with non-released dependencies.
