Thank you Patrick.
Starting with creation of the first release candidate
Regards
Nabarun Nag
On Thu, Sep 13, 2018 at 11:39 AM Patrick Rhomberg
wrote:
> Revert of 5600 commits pushed to release/1.7.0. Built clean locally and
> `$> gfsh version --full` is behaving as expected.
>
> On Thu, Sep 13
Revert of 5600 commits pushed to release/1.7.0. Built clean locally and
`$> gfsh version --full` is behaving as expected.
On Thu, Sep 13, 2018 at 9:49 AM, Nabarun Nag wrote:
> GEODE-5727 is closed and merged to release/1.7.0
> Thank you Jinmei
>
> On Thu, Sep 13, 2018 at 9:47 AM Nabarun Nag wr
GEODE-5727 is closed and merged to release/1.7.0
Thank you Jinmei
On Thu, Sep 13, 2018 at 9:47 AM Nabarun Nag wrote:
> Thank you Patrick. Please do send a notification email once this is
> reverted in the release/1.7.0 branch.
> Thank you Jinmei for putting the fix for GEODE-5727 into release/1.
Thank you Patrick. Please do send a notification email once this is
reverted in the release/1.7.0 branch.
Thank you Jinmei for putting the fix for GEODE-5727 into release/1.7.0.
However the GEODE ticket is still in open state. Can it be closed?
Regards
Nabarun Nag
On Thu, Sep 13, 2018 at 9:21 AM
Sounds like we have a plan! I'll take it upon myself to do the revert.
On Thu, Sep 13, 2018 at 7:24 AM, Sai Boorlagadda
wrote:
> +1 to revert and fix on develop
>
> On Wed, Sep 12, 2018, 4:43 PM Nabarun Nag wrote:
>
> > Reverting them on release/1.7.0 will bring it to the previous status quo,
+1 to revert and fix on develop
On Wed, Sep 12, 2018, 4:43 PM Nabarun Nag wrote:
> Reverting them on release/1.7.0 will bring it to the previous status quo,
> how all previous releases were done. I don't think anyone will build
> release/1.7.0 repeatedly, hence there is no advantage of making bu
How do you retrieve git metadata when building from a source distribution (not
a repo)? That is why .buildinfo exists *in the source distribution*.
Anthony
> On Sep 12, 2018, at 4:30 PM, Patrick Rhomberg wrote:
>
> Okay. So that information is definitely coming from the
> GemFireVersion.pro
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.
+1 for revert
On Wed, Sep 12, 2018 at 4:42 PM, Nabarun Nag wrote:
> Reverting them on release/1.7.0 will bring it to the previous status quo,
> how all previous releases were done. I don't think anyone will build
> release/1.7.0 repeatedly, hence there is no advantage of making build
> process f
Reverting them on release/1.7.0 will bring it to the previous status quo,
how all previous releases were done. I don't think anyone will build
release/1.7.0 repeatedly, hence there is no advantage of making build
process faster for that branch.
Whereas on develop a more appropriate solution can be
Okay. So that information is definitely coming from the
GemFireVersion.properties file, which explains this issue. Either
reverting the previous GEODE-5600 changes or resolving merge conflicts from
PR 2457 would address this issue.
My concern remains about the .buildinfo file, however.Is the
@patrick
if you build geode release branch 1.7.0 "./gradlew clean build
-Dskip.tests=true -xdocs -xjavadoc" and start gfsh from
geode-assembly/build/install/apache-geode/bin/gfsh
And then type `version --full` you get this
gfsh>version --full
Build-Date: 2018-09-12 16:07:03 -0700
Build-Id: nnag 0
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
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
N
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 wrote:
> Should we include the fix for GEODE-5727 in the 1.7 release as w
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 m
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
change
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 dev
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]
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
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 wrote:
>
> Hello Anthony,
>
> I plan to do that while creat
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 wrote:
> Looks good Naba! Only thing I see right now is that buil
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 wrote:
>
> CORRECTION: if '*no*' concerns are raised, we will start with the voting
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 wrote:
> Hello Geode Dev Community,
>
> We have created a new release branch for Apache Geode 1.7.0 -
> "release/1.7.0"
>
> Pre
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
25 matches
Mail list logo
