The most important thing for the purposes of what we’re trying to achieve is to have a unique non overridable version. In principle, a unique tag with release timestamp should be enough, as long as we can uniquely reference it.
However, even then, I’d say release frequency (establishing “base”) for releases should be at least slightly relaxed compared to Cassandra itself. I will investigate whether it is possible to avoid voting for test only dependencies, since I’d much rather have it under Apache umbrella, as I was previously skeptical of a dependency that I believed shouldn’t have been locked under contributor’s GitHub. If test only no-vote option isn’t possible due to legal reasons, we can proceed with snapshot+timestamp and release-rebase with a 24h simplified vote. Thanks, —Alex On Wed 15. Apr 2020 at 19:24, Mick Semb Wever <m...@apache.org> wrote: > > Apache release rules were made for first-class projects. I would like to > > propose simplifying voting rules for in-jvm-dtest-api project [1]. > > > I am not sure the PMC can simply vote away the ASF release rules here. > But it should be possible to implement the proposal by stepping away > from what the ASF considers a release and work with "nightlies" or > snapshots. The purpose of an "ASF release" has little value to > in-jvm-dtest-api, IIUC. > > For example you can't put artifacts into a public maven repository > without a formal release vote. AFAIK the vote process is there for the > sake of the legal protections the ASF extends to all its projects, > over any notion of technical quality of the release cut. > > And we are not supposed to be including binaries in the source code > artifacts, at least not for anything that runtime code depends on. > > Solutions to this could be… > - allowing snapshot versions of test scope dependencies*, downloaded > from the ASF's snapshot repository⁽¹⁾ > - making an exception for a binary if only used in test scope (i > believe this is ok), > - move in-jvm-dtest-api out of ASF (just have it as a github project, > and publish as needed to a maven repo) > > You could also keep using `mvn release:prepare` to cut the versions, > but just not deploy them to ASF's distribution channels. > > This whole area of ASF procedures is quite extensive, so i'd > definitely appreciate being correctly contradicted :-) > > My vote would be to take the approach of using the snapshot > repository. Semantic versioning has limited value here, and you would > be able to have a jenkins build push the latest in-jvm-dtest-api > artifact into the snapshot repository using a uniqueVersion so that it > can be referenced safely in the build.xml (avoiding having to check > the jar file into the cassandra/lib/ folder). > > regards, > Mick > > ⁽¹⁾ https://repository.apache.org/content/groups/snapshots/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- alex p
