Release process for Apache Geode wiki

Hi, I have created a new wiki page on how to release Apache Geode. Please do a review and let me know if there are any suggestions or modifications required. https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode Regard Nabarun Nag

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1066 was SUCCESSFUL (with 2456 tests)

--- Spring Data GemFire > Nightly-ApacheGeode > #1066 was successful. --- Scheduled 2458 tests in total. https://build.spring.io/browse/SGF-NAG-1066/ --

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

#3 first and then work towards #1, then #2. We can document what "--add-open" options needs to be added to start client if running with jdk11+ in the meantime. I also have reservations about how #4 works. If it works, it is a good alternation for #3. On Wed, Oct 10, 2018 at 2:23 PM Sai

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

+1 to Dan's idea if its possible. There is a maven plugin to invoke javac twice with respective java targets. https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan wrote: > er, lost the end of that first sentence

Re: [DISCUSS] Java 11 jobs in the pipeline

+1 to keeping them off the main tab. Having red jobs that aren't actionable will train us to ignore red jobs. On Wed, Oct 10, 2018 at 2:13 PM Dan Smith wrote: > I feel like it would be better to keep the Java 11 jobs off of the main tab > in the pipeline until they are actually working. In the

[DISCUSS] Java 11 jobs in the pipeline

I feel like it would be better to keep the Java 11 jobs off of the main tab in the pipeline until they are actually working. In the spirit of keeping develop releasable, we should keep the main pipeline clean and only include what is releasable today in the pipeline. Thoughts? -Dan

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

er, lost the end of that first sentence there. I think that reducing dependencies on Unsafe is a good goal regardless. On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan wrote: > #1 sounds awesome but may be unrealistic given our advertised feature set. > I think that reducing dependencies on

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

#1 sounds awesome but may be unrealistic given our advertised feature set. I think that reducing dependencies on Unsafe If we can conditionally use Jigsaw modules for Java versions later than 8 while maintaining Java 8 compatiblity, that seems like the best solution. +2 to Dan's idea if it

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

Here is a discussion from Google Guava project about compiling module-info.java in Java 9+ and including it in a jar with classes compiled for Java 8. https://github.com/google/guava/issues/2970 On Wed, Oct 10, 2018 at 1:39 PM Jacob Barrett wrote: > I like Dan’s idea! I would rather we work

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

I like Dan’s idea! I would rather we work towards the correct solution. > On Oct 10, 2018, at 1:22 PM, Dan Smith wrote: > > #2 seems like the least hacky way to continue using things like > sun.misc.Unsafe. Could we just compile a module-info.java with Java 9 and > bundle it? This would also

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

Also, for #3, what does it look like to run a client application? IOW, what are the command-line arguments needed? Anthony > On Oct 10, 2018, at 1:29 PM, Anthony Baker wrote: > > Do you have a listed of restricted API’s that are used by Geode? Which > libraries used by Geode are affected?

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

Do you have a listed of restricted API’s that are used by Geode? Which libraries used by Geode are affected? Are these run-time only warnings or actual errors? Anthony > On Oct 10, 2018, at 12:20 PM, Owen Nichols wrote: > > Goal: > > Run Geode on Java 11 (GEODE-3 >

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

#2 seems like the least hacky way to continue using things like sun.misc.Unsafe. Could we just compile a module-info.java with Java 9 and bundle it? This would also help consumers of geode that want to use Java 9 modules. I'm a little bit sceptical of this permit-reflect libary, seeing as it's

Re: Concourse upgrade

Concourse runs have started to fail ERROR: JAVA_HOME is set to an invalid directory: /usr/lib/jvm/java--openjdk-amd64 Please set the JAVA_HOME variable in your environment to match the location of your Java installation. On 10/10/18 11:03 AM, Sean Goller wrote: We're going to be

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

I vote for #1, with #4 as a stopgap Isn't a goal of Java 11 support in Geode that we can use the new Java modules system? If so, let's actually try and get there. I think stability would actually improve by using public API instead of internals, and performance fears are just that: fears, until

Re: Geode Native & Apache Geode 1.8 Release

Good work team. +1 to get this as part of Geode 1.8 release. It will be good to see community taking advantage of this. And building new native client apps. I assume it will have all the docs about client-server compatibility version info. And framework for backward compatibility testing with new

[DISCUSS] permit-reflect vs --add-opens for Java 11 support

Goal: Run Geode on Java 11 (GEODE-3 ). Problem: Java 8 allows Geode (and its 3rd party libraries) full access to all Java APIs, including internal APIs. However, Java 11 restricts access to many of these APIs by default. Solution #1: Remove

Re: Geode Native & Apache Geode 1.8 Release

+1 for a source release On Wed, Oct 10, 2018 at 12:59 PM Anthony Baker wrote: > I think starting with a source-only release of the native client is a good > first step. That lets us focus on verifying that all the tasks outlined in > [1] are complete and correct. > > Anthony > > [1]

Re: Geode Native & Apache Geode 1.8 Release

I think starting with a source-only release of the native client is a good first step. That lets us focus on verifying that all the tasks outlined in [1] are complete and correct. Anthony [1] https://issues.apache.org/jira/browse/GEODE-1416 > On Oct 10, 2018, at 11:52 AM, Dan Smith wrote:

Re: Geode Native & Apache Geode 1.8 Release

That is awesome! Let's get it in! I think there are some details to work out: - Do we need to build any automation for creating the native source release (similar to ./gradlew srcDist on the java side)? - Will we release binaries? Which platforms and how to does the release manager build them?

Re: [VOTE] Time-based release schedule for minor releases

To my mind, one of the core reasons for SemVer is to communicate the level of estimated risk to users when taking an update. It seems to me that the amount of code change included in a quarterly release will always introduce more risk than a single narrowly-targeted fix for a CVE (like those that

Re: [VOTE] Time-based release schedule for minor releases

Practically speaking I think I agree with Anthony.  I'm changing my vote to +0 but I do still feel that we're not going to be following the spirit of our major/minor/patch definitions.  A quarterly release might be a Minor release or it might be a Patch release, depending on whether there are

Re: [VOTE] Time-based release schedule for minor releases

If you look through the 350+ JIRA’s fixed for 1.7.0 it’s not only bug fixes—there are improvements and new additions. IMO, using a Minor version designation was the correct choice and fits with semver guidelines. Anthony > On Oct 10, 2018, at 10:31 AM, Robert Houghton wrote: > > Alexander,

Concourse upgrade

We're going to be upgrading the concourse infrastructure to the latest version today, since 1.7 has been released. Best case it will be fairly seamless and everything will be unicorns and puppies and happiness. Worst case it'll be messed up for a few days. -Sean.

Re: [VOTE] Time-based release schedule for minor releases

Sure! I am all in for time-based releases. I see the point that we can only do Minors as patches(or maintenance) are reserved for hotfixes and security bugs. So +1 for a time-based release to ship whatever has changed since the last release. On Wed, Oct 10, 2018 at 10:29 AM Alexander Murmann

Re: [VOTE] Time-based release schedule for minor releases

Sai, I think what you are saying is theoretically 100% correct. As Anthony points out in practice we'd never go for three months without a single feature. I think it makes sense to agree to aim for the quarterly release being a minor release as opposed to aiming for a patch or major. If we aimed

Re: [VOTE] Time-based release schedule for minor releases

Looking at the current definition it sounds like we can only decide if its a Minor at the time of release and cannot be scheduled. Thoughts? *> MINOR*: Minor releases can contain minor new features and must definitely include significant improvements > to current API or components that justify

Re: [VOTE] Time-based release schedule for minor releases

+0 Willing to try any reaonable plan that emerges. Would like to see some articulation of an "upgrade policy" if such things exist in the open source universe. That is, will each quarterly (or whatever) release necessarily be backward compatible with the previous release? Will a user be able to

Re: [VOTE] Time-based release schedule for minor releases

Practically speaking, a quarterly release cycle means there’s *always* some feature addition or improvement included in the release. That’s why I agree with the suggestion of a release cadence based on minor version bumps. See [1] for the outcome of prior discussions on SemVer. Anthony [1]

Re: [VOTE] Time-based release schedule for minor releases

I’m with Sai that it seems like we need to clear up our definitions of minor versus patch releases. The referenced SemVer definition indicates that any backwards compatible bug fix qualifies for a patch release. But it was stated earlier that only security-related or critidal bug fixes justify a

Geode Native & Apache Geode 1.8 Release

Hi, The Geode Native components (https://github.com/apache/geode-native) have made tremendous progress since its original donation to Apache. The project is nearing a release candidate and I propose that the *first official release of Geode Native be included in Apache Geode 1.8.* Since

Re: [VOTE] Time-based release schedule for minor releases

+1 for a cadence based release cycle that using 3-month between minor releases. On Wed, Oct 10, 2018 at 7:29 AM Sai Boorlagadda wrote: > After looking at these definitions are we not talking about time-based > patch releases? > It is again subjective how much functionality makes a MINOR

Re: [VOTE] Time-based release schedule for minor releases

After looking at these definitions are we not talking about time-based patch releases? It is again subjective how much functionality makes a MINOR release. Though this thread is seeking consensus on time-based scheduled it is specifically for minors. it appears to me like we need to update our