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%7Cbblake%40vmware.com%7Cb2eb424632174cd66c2408d82afee313%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637306621505139591&sdata=DWUOSFvwEnJDJytU7qSjrzFEzR8gzjIm96pXAOqnxUQ%3D&reserved=0
