I think as long as we don’t publish the artifacts to maven central or some other location that is for “anyone” we do not need a formal release. Even then since the artifact is only meant for use by people developing C* that might be fine.
If artifacts are only for use by individuals actively participating in the development process, then no formal release is needed. See the definition of “release” and “publication” found here: http://www.apache.org/legal/release-policy.html#release-definition > DEFINITION OF "RELEASE" > <http://www.apache.org/legal/release-policy.html#release-definition> > Generically, a release is anything that is published beyond the group that > owns it. For an Apache project, that means any publication outside the > development community, defined as individuals actively participating in > development or following the dev list. > > More narrowly, an official Apache release is one which has been endorsed as > an "act of the Foundation" by a PMC. > > > PUBLICATION <http://www.apache.org/legal/release-policy.html#publication> > Projects SHALL publish official releases and SHALL NOT publish unreleased > materials outside the development community. > > During the process of developing software and preparing a release, various > packages are made available to the development community for testing > purposes. Projects MUST direct outsiders towards official releases rather > than raw source repositories, nightly builds, snapshots, release candidates, > or any other similar packages. The only people who are supposed to know about > such developer resources are individuals actively participating in > development or following the dev list and thus aware of the conditions placed > on unreleased materials. > -Jeremiah > On Apr 15, 2020, at 3:05 PM, Nate McCall <zznat...@gmail.com> wrote: > > Open an issue with the LEGAL jira project and ask there. > > I'm like 62% sure they will say nope. The vote process and the time for > such is to allow for PMC to review the release to give the ASF a reasonable > degree of assurance for indemnification. However, we might have a fair > degree of leeway so long as we do 'vote', it's test scope (as Mick pointed > out) and the process for such is published somewhere? > > Cheers, > -Nate > > On Thu, Apr 16, 2020 at 7:20 AM Oleksandr Petrov <oleksandr.pet...@gmail.com> > wrote: > >> 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 >>
