I have no current plans on backporting, though it might make the continued Concourse testing of those branches easier.
There is a PR about this available: https://github.com/apache/geode/pull/5057 On Thu, Apr 30, 2020 at 9:25 PM Owen Nichols <onich...@pivotal.io> wrote: > It sounds like the only impact is that downstream projects that consume > -SNAPSHOT builds will need to make one small change to their maven config; > downstream projects that consume release versions will be unaffected. So > just let us know when to make that change. > > Anytime soon after support/1.13 is cut would be great to bring this change > to develop. Assuming it goes smoothly on develop, would you envision > backporting to support/1.13 and support/1.12 as well? > > > On Apr 30, 2020, at 8:38 PM, Robert Houghton <rhough...@pivotal.io> > wrote: > > > > I don't read any strong negatives to this change. I would like to start > > polishing a PR on this work, unless anyone has strong opposing feelings. > > Does anyone feel that this change requires a VOTE? > > > > On Tue, Apr 28, 2020 at 10:36 AM Jacob Barrett <jbarr...@pivotal.io> > wrote: > > > >> 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". > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >> > >> > >
