Probably for a separate discussion but I would opt for a future where the release manager validates and signs a specific build from produced by the CI. This takes a lot of error away in the what the release manager currently does, which has resulted in incorrect artifacts being voted on.
In this model the release manager would be certifying a release with full version number, or whatever we choose for the release version number. Until then the release manager could just use the short number. In Gradle/Maven versioning a version without qualifier is always newer than one with. So 1.13.0 is newer than any 1.13.0-build.123. -Jake > On Apr 28, 2020, at 10:24 AM, Anthony Baker <aba...@pivotal.io> wrote: > > Note that I’m asking about building on my local system. Will the version > listed in gradle.properties use the full 1.13.0-build.123 syntax? How would > it get bumped? > > Would a release manager end up using just 1.13.0? Hoping for yes :-) > > Anthony > >> On Apr 28, 2020, at 9:24 AM, Robert Houghton <rhough...@pivotal.io> wrote: >> >> @anthony >> /develop would say 1.13.0-build.230 (as of this morning). >> Once cut, /release/1.13 would say 1.13.0-build.231, and /develop would >> switch to 1.14.0-build.1. >> >> gfsh would return that full value. That is the artifact version. >> >> On Mon, Apr 27, 2020 at 4:38 PM Anthony Baker <bak...@vmware.com> wrote: >> >>> If I build the /develop branch and run `gfsh version` what will it print? >>> >>> If I build the soon-to-be /release/1.13 branch and run `gfsh version` what >>> will it print? >>> >>> Anthony >>> >>> >>> On 4/27/20, 4:32 PM, "Robert Houghton" <rhough...@pivotal.io> wrote: >>> >>> The artifact would change from "1.13.0-SNAPSHOT" to "1.13.0-build.123". >>> >>> >>> >>> >>> >
