+1 to jitpack On Fri, Apr 17, 2020 at 8:50 AM Oleksandr Petrov <oleksandr.pet...@gmail.com> wrote:
> 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 > -- http://twitter.com/tjake
