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://issues.apache.org/jira/browse/GEODE-8016 > >> [2] > >> > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples > > > >
