> You would reference the snapshot dependency by the timestamped snapshot. This > makes it a reproducible build.
How confident are we that the repository will not alter or delete them? > linking in the source code into in-tree is a significant thing to do Could you explain why? I thought your preferred alternative was merging the source trees permanently > On 17 Jan 2023, at 21:40, Mick Semb Wever <m...@apache.org> 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.
