I was taking with Alex on slack earlier today brainstorming ideas and two that might work are using a git submodule to reference the code by git hash, so no release needed, or using jitpack.io to be able to pull the jar down by git hash without doing a release.
Does anyone find either of those options more appealing than 1/2/3? -Jeremiah > On Apr 16, 2020, at 6:14 PM, David Capwell <dcapw...@gmail.com> wrote: > > Not a fan of 2 or 3. For #2 there is also talk about getting rid of the > jars in /lib so that would complicate things. > > I think frequent releases with snapshots per commit is good. Agree with > Nate we should document this so we have something we can always point to. > >> On Thu, Apr 16, 2020 at 2:54 PM Nate McCall <zznat...@gmail.com> wrote: >> >> (1) sounds reasonable to me. I'd like us to document the vote cycle and >> release train specifics on cassandra.a.o somewhere (developer and releases >> pages maybe?). Nothing exhaustive, just 'we do X with Y'. >> >> >> On Thu, Apr 16, 2020 at 11:03 PM Oleksandr Petrov < >> oleksandr.pet...@gmail.com> wrote: >> >>> I've posted the question on the legal-discussion mailing list, and got >> some >>> helpful responses. >>> >>> We can't work around the vote, best we can do is make it shorter (3 +1 >>> votes / 24 hours). We have several options now: >>> >>> 1. Release SNAPSHOT builds prefixed with in-jvm dtest commit SHAs and cut >>> release every week or so (release-train if you wish) >>> 2. Avoid using Apache repository for releases altogether, and just push >>> jars to Cassandra repository >>> 3. Make this code "unofficial" (publish and manage outside Apache) >>> >>> I'm not a big fan of (2), since we already tried that with Python and >> Java >>> drivers, also I'm not sure about binaries in git. As regards (3), I'm not >>> sure if this makes it harder for the folks who rely on Apache legal >>> framework for contributions. >>> >>> Unless there are strong opinions against (1), which seems to be a >>> reasonable middle ground, we can do it. Please let me know if you also >> have >>> other ideas. >>> >>> Thank you, >>> -- Alex >>> >>> On Wed, Apr 15, 2020 at 10:33 PM Jeremiah D Jordan < >> jerem...@datastax.com> >>> wrote: >>> >>>> 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 >>>>>> >>>> >>>> >>> >>> -- >>> alex p >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
