-1
I often need to build geode-examples on older geode version (more frequent than
current version).
One more irrelevant comments: we do need to enhance our geode-examples. The
current examples are too weak.
On 7/30/20, 8:16 AM, "Blake Bender" <bbl...@vmware.com> wrote:
FWIW, Geode Native works around this by not keeping a separate examples
repo at all. To build our examples, you *must* build your own Geode Native
"installation," which includes the examples tree, or download the desired
tarball/zip file from our GitHub releases.
I’m pretty much agnostic as to which way we should go for any particular
repository, which is why I wrote "remove or rename" in the title of GEODE-8335.
Let's do the right thing for each repo, but not expend a ton of brain power on
it. I brought this up as a *small* gesture we should make in the name of
kindness, not a large effort.
Thanks,
Blake
On 7/18/20, 2:42 AM, "Owen Nichols" <onich...@vmware.com> wrote:
Voting Results:
+1: 5 votes
0: 0 votes
-1: 1 vote
The voting is successful by majority vote. INFRA has completed the
requested change and git clone g...@github.com:apache/geode-examples.git now
checks out develop, making geode-examples consistent with all other geode-
projects, and clearing the way to eliminate master from all projects if @Blake
or anyone else would like to move forward on that.
Although it didn't seem to sway anyone else, let's still attempt to
discuss/address @Anthony's concern that develop doesn't pair well with released
versions of Geode.
Maybe the brew install + git clone workflow is not how we want to
introduce an application developer to Geode. We could suggest: if cloning from
git, clone everything from git; if using released artifacts, use release
artifacts for everything. If mix-n-match is necessary, the README.md could
explain how to check out the correct branch or tag (or specify the Geode
version parameter in the gradle command) to match the installed version of
Geode.
It's important and fundamental for application developers to be aware
that client version must be <= server version, so perhaps it's beneficial to
document that from the beginning.
Another idea might be improving the error message when the client
version is too new?
We could also modify the release scripts to substitute the latest
release version into the README as part of the release process, to keep the
out-of-the-box experience as simple as copy-and-pasting a gradle command from
the README.
@Anthony I'd be happy to pair with you on updating the README or any
other scripts/documentation.
If anyone else has thoughts or ideas, please chime in.
On 7/14/20, 7:16 AM, "Anthony Baker" <bak...@vmware.com> wrote:
Consider the use case of an application developer who wants to run
geode-examples against the latest geode release:
1) brew install apache-geode
2) git clone geode-examples
3) Get some runtime errors because geode-examples won’t connect to
a previous geode release
At this point, you have to do some detective work to either
download the geode-examples from the corresponding source release or switch
over to the appropriate git tag.
I think there’s value in maintaining a default branch of
geode-examples that tracks the latest release.
Anthony
> On Jul 9, 2020, at 9:39 PM, Owen Nichols <onich...@vmware.com>
wrote:
>
> A fresh checkout of geode and all but one geode-<relatedproject>
repos checks out develop as the Default branch.
>
> The lone exception is geode-examples. Please vote +1 if you are
in favor of changing its Default branch to develop for consistency with the
other repos and other reasons as per recent discussion[1].
>
> [1]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fx%2Fthread.html%2Frfec15c0a7d5d6d57beed90868dbb53e3bfcaabca67589b28585556ee%40%253Cdev.geode.apache.org%253E&data=02%7C01%7Czhouxh%40vmware.com%7Cd42c339465e54b6ad5af08d8349b7bc4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637317189691026288&sdata=iQD%2F3%2Bw4LXhrI6dczqML2vm%2Fc72YyKO80ueOu4elViI%3D&reserved=0
