Do we know if this is an issue that other open source projects have dealt with? And if so, is this proposed solution similar to what they might have done to remedy it? ________________________________ From: Robert Houghton <rhough...@pivotal.io> Sent: Monday, April 27, 2020 4:31 PM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [DISCUSS] Publish Builds, not Snapshots
The artifact would change from "1.13.0-SNAPSHOT" to "1.13.0-build.123". The number after the "build" slug is auto-incremented by our CI system anyway, as the "geode-build-version" semver resource. We are actually doing *more* work in Gradle to truncate that number from the current "SNAPSHOT" value. On Mon, Apr 27, 2020 at 3:41 PM Anthony Baker <aba...@pivotal.io> wrote: > @Robert, can you show some examples of what the build number would be > under this proposal? Does 1.13.0-SNAPSHOT become 1.13.0.N where N > increments every build? > > Seems reasonable. Since the consumers of pre-release artifacts are either > a) this project or b) close related projects for > integration-testing-purposes-only I’m not super worried about the ugly > syntax. > > > Anthony > > > > On Apr 27, 2020, at 3:25 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > > > It is unfortunate that the Maven/Gradle community hasn’t addressed this > glaring issue with SNAPSHOT for decades now (well maybe not decades but > certainly decade). It is also unfortunate that the Maven version coordinate > is ugly. Aside from that I am totally onboard. Yay for reproducible builds > and predictable downstream builds! > > > > With SNAPSHOTS in a repo the repository automatically prunes back old > builds. Do we have any concerns about having a plethora of builds filling > up this new pre-release repository? > > > > -Jake > > > >> On Apr 27, 2020, at 3:21 PM, Robert Houghton <rhough...@pivotal.io> > wrote: > >> > >> Hello to the community, > >> > >> tl;dr - Lets publish builds, not snapshots, for repeatable CI builds, as > >> GEODE-8016[1]. Communicate desired artifact version via the existing > >> 'UpdatePassingTokens' job. > >> > >> I have been working on the Geode build and CI systems for a long time, > and > >> it has irked me that the geode-examples pipeline[2] does not build and > test > >> against the latest artifacts from the develop pipeline. Some work has > been > >> done already to allow this via "composite" builds for local testing > without > >> needing to publish Geode to your local Maven repository. > >> > >> From a Concourse CI perspective, composite builds are costly due to the > >> rebuild of the upstream artifacts. They allow repeatable builds, but > only > >> by rebuilding those dependencies. Better would be to point to upstream > >> artifacts as concrete build versions. SNAPSHOT builds can and do roll > >> (invisibly) as new versions are published. Discrete, numbered builds do > >> not. Downstream consumers can use greedy version specifiers to get their > >> current behavior of "latest". > >> > >> Gradle: 'org.apache.geode:geode-core:1.13.0+' > >> Maven: '<groupId>org.apache.geode</group>' > >> '<artifactId>geode-core</name>' > >> '<version>[1.13.0,1.14.0)</version>' > >> > >> What do you all think? Discuss! > >> -Robert Houghton > >> > >> [1] > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8016&data=02%7C01%7Cdoevans%40vmware.com%7Cf1b924b4bfe04438773a08d7eb033b08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637236271422916825&sdata=gRQFRLGueu5x8FxRIsdXeKM5PmZLBT6uW8Dgh7FAx2s%3D&reserved=0 > >> [2] > >> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-examples&data=02%7C01%7Cdoevans%40vmware.com%7Cf1b924b4bfe04438773a08d7eb033b08%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637236271422916825&sdata=g6mfjOLQrkbpS9UWC9QBQL37rcFASIUo5PG0rCs1eAU%3D&reserved=0 > > > >
