1) User downloads source distribution [1] 2) User runs `gradle build` 3) User runs `gfsh version --full`
The .buildinfo file contains the information that should go into the GemFireVersion.properties file. Does that help? Anthony [1] http://apache.org/dyn/closer.cgi/geode/1.6.0/apache-geode-1.6.0-src.tgz > On Sep 12, 2018, at 3:51 PM, Patrick Rhomberg <prhomb...@pivotal.io> wrote: > > I'm happy to work on those reverts, although if Anthony could elaborate on > where exactly the version information was missing, that assuage some of my > own worries as to whether it's the right approach. It's still not clear to > me where .buildinfo is intended to be consumed. > > On Wed, Sep 12, 2018 at 3:08 PM, Nabarun Nag <n...@apache.org> wrote: > >> Yes Alexander, we are still waiting on the build info reverts from Patrick, >> so, I think that this can be put into release/1.7.0. >> >> Sure Jinmei, you can go ahead and merge the change into release/1.7.0 >> branch too when you merge the PR. Please do close the fixed version in the >> JIRA as 1.7.0 >> >> Regards >> Nabarun Nag >> >> >> On Wed, Sep 12, 2018 at 2:50 PM Alexander Murmann <amurm...@pivotal.io> >> wrote: >> >>> While there is a workaround this looks like a highly visible bug with a >>> fairly safe fix. I am in favor of merging, since the branch is still >>> distressed anyways. >>> >>> Other opinions? >>> >>> On Wed, Sep 12, 2018 at 2:29 PM, Jinmei Liao <jil...@pivotal.io> wrote: >>> >>>> Should we include the fix for GEODE-5727 in the 1.7 release as well? >>>> >>>> Without the fix, the command "export cluster-config >>> --zip-file-name=x.zip" >>>> would fail with NPE, user has to use "export cluster-config >>>> --zip-file-name=./x.zip" in order for export to work. >>>> >>>> PR for this fix is ready and could be merged soon. >>>> >>>> Jinmei >>>> >>>> >>>> On Wed, Sep 12, 2018 at 11:12 AM Patrick Rhomberg < >> prhomb...@apache.org> >>>> wrote: >>>> >>>>> I'm not sure PR 2457 will help with an ignored .buildinfo, but I'm >> not >>>> sure >>>>> as to why .buildinfo would be getting ignored by anything, either. >>>>> >>>>> PR 2457 deals with the still-needs-to-be-renamed >>>> GemFireVersion.properties >>>>> file and when it is generated. Previously, it was whenever the git >>> index >>>>> changed, which was too frequent. Not it is whenever the source >>>> parameters >>>>> are passed on the command-line with the build, which has presented >>> issues >>>>> outside the Concourse pipeline. PR 2457 splits the difference, >>>>> regenerating the file anytime the SHA changes. >>>>> >>>>> The only interaction with .buildinfo that I can see is that if the >>> build >>>>> was run on a machine that was missing git, it would attempt to read >>>> values >>>>> instead from .buildinfo when creating the GemFireVersion.properties >>> file. >>>>> >>>>> I guess I don't fully understand the problem Anthony has called out. >>>> Where >>>>> is it exactly that information previously gathered from .buildinfo is >>> now >>>>> missing? And are we certain that it was indeed pulling from >> .buildinfo >>>> and >>>>> not the aforementioned GemFireVersion.properties? >>>>> >>>>> On Wed, Sep 12, 2018 at 10:11 AM, Alexander Murmann < >>> amurm...@pivotal.io >>>>> >>>>> wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> It seems like that PR doesn't address the missing SHA issue either >>> and >>>> I >>>>> am >>>>>> not aware of any proposals to properly fix this. How viable is it >> to >>>>> revert >>>>>> the relevant Gradle build changes on support/1.7? >>>>>> We could continue make the new Gradle approach work with our >> release >>>>>> process on develop and hopefully release 1.8 with these changes. >>>>>> >>>>>> Are there any other proposals to unblock this? >>>>>> >>>>>> On Tue, Sep 11, 2018 at 5:41 PM, Anthony Baker <aba...@pivotal.io> >>>>> wrote: >>>>>> >>>>>>> Slight clarification—the issue I mentioned is when a user builds >>>> Geode >>>>>>> from the source distribution. The source distribution that the >>>> release >>>>>>> manager creates has the correct .buildinfo file, it’s just >> ignored >>> by >>>>> the >>>>>>> build. In short, the release manager can’t work around the >>> problem. >>>>>>> >>>>>>> Does [1] help with this? >>>>>>> >>>>>>> Anthony >>>>>>> >>>>>>> [1] https://github.com/apache/geode/pull/2457 < >>>>>> https://github.com/apache/ >>>>>>> geode/pull/2457> >>>>>>> >>>>>>> >>>>>>>> On Sep 11, 2018, at 3:16 PM, Alexander Murmann < >>>> amurm...@pivotal.io> >>>>>>> wrote: >>>>>>>> >>>>>>>> What's the consensus on the version info issue Anthony is >> calling >>>>> out? >>>>>>> Does >>>>>>>> anyone have a proposal for fixing this for this release? Should >>>>> Nabarun >>>>>>> as >>>>>>>> the release manager manually correct this for the release and >> we >>>>> find a >>>>>>>> permanent solution for 1.8? >>>>>>>> >>>>>>>> On Mon, Sep 10, 2018 at 12:33 PM, Anthony Baker < >>> aba...@pivotal.io >>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>>> Unfortunately it would require a fix to the build—it’s not >> about >>>>>>> producing >>>>>>>>> the release candidate. It’s when a user builds from the source >>>>> release >>>>>>> that >>>>>>>>> the version info is ignored. >>>>>>>>> >>>>>>>>> Anthony >>>>>>>>> >>>>>>>>>> On Sep 10, 2018, at 10:02 AM, Nabarun Nag <n...@apache.org> >>>> wrote: >>>>>>>>>> >>>>>>>>>> Hello Anthony, >>>>>>>>>> >>>>>>>>>> I plan to do that while creating the release candidate. If >>> there >>>>> are >>>>>> no >>>>>>>>>> concerns raised on the release branch, I will start with the >>>>> process >>>>>>>>> soon. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Nabarun Nag >>>>>>>>>> >>>>>>>>>>> On Mon, Sep 10, 2018 at 8:51 AM Anthony Baker < >>>> aba...@pivotal.io> >>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Looks good Naba! Only thing I see right now is that >> building >>>> from >>>>>> the >>>>>>>>>>> source distribution does not use the .buildinfo file, >> leaving >>>> the >>>>>>>>> version >>>>>>>>>>> string empty. >>>>>>>>>>> >>>>>>>>>>> Anthony >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Sep 7, 2018, at 9:15 AM, Nabarun Nag <n...@apache.org> >>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> CORRECTION: if '*no*' concerns are raised, we will start >> with >>>> the >>>>>>>>> voting >>>>>>>>>>>> for the release candidate soon. >>>>>>>>>>>> >>>>>>>>>>>> Regrads >>>>>>>>>>>> Nabarun Nag >>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Sep 7, 2018 at 9:08 AM Nabarun Nag < >> n...@pivotal.io >>>> >>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello Geode Dev Community, >>>>>>>>>>>>> >>>>>>>>>>>>> We have created a new release branch for Apache Geode >> 1.7.0 >>> - >>>>>>>>>>>>> "release/1.7.0" >>>>>>>>>>>>> >>>>>>>>>>>>> Previous branch was deleted and has been replaced with a >>> fresh >>>>>> one. >>>>>>>>>>>>> >>>>>>>>>>>>> Please do review and raise any concern with the release >>>> branch. >>>>>>>>>>>>> >>>>>>>>>>>>> If concerns are raised, we will start with the voting for >>> the >>>>>>> release >>>>>>>>>>>>> candidate soon. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Nabarun Nag >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> Regards >>>>>>>>>> Nabarun Nag >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Cheers >>>> >>>> Jinmei >>>> >>> >> -- >> Regards >> Nabarun Nag >>
