Thank you for suggestions, Jeremiah! I first really liked the idea of jitpack since I thought it clones repository and builds stuff locally. However, it seems like they build on their machines in docker container. While this is something that could be useful in many cases, I think just using snapshots with hash would yield a similar result.
Another suggestion from Jeremiah was to use submodules, which could be helpful for IDE. We can explore this in future, I just do not have capacity at the moment to figure out how to make sure it all builds with ant to make it work nicely for developers. @Nate McCall <zznat...@gmail.com> I've added some information about deployment to readme file [1], and have also posted how to build a snapshot [2]. I'll add information about the length of vote with a reference to this mailing list discussion for history. -- Alex [1] https://github.com/apache/cassandra-in-jvm-dtest-api/blob/master/README.md [2] https://github.com/apache/cassandra-in-jvm-dtest-api/commit/29d055b7cffc66a852505660930c980c185138a1 On Fri, Apr 17, 2020 at 1:34 AM J. D. Jordan <jeremiah.jor...@gmail.com> wrote: > 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 > > -- alex p
