Release process for Apache Geode wiki

[Nabarun Nag]

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 CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #1066 was successful.
---
Scheduled
2458 tests in total.

https://build.spring.io/browse/SGF-NAG-1066/





--
This message is automatically generated by Atlassian Bamboo

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

[Jinmei Liao]

#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 Boorlagadda 
wrote:

> +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 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 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 allows this.
> > >
> > > On Wed, Oct 10, 2018 at 1:47 PM Jacob Barrett 
> > wrote:
> > >
> > >> 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 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 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
> > >> > > been around for about 1 month, has 0 tests in the source that I
> can
> > >> see,
> > >> > > and seems to be tripling down on relying on sun.misc.Unsafe to do
> > >> stuff.
> > >> > > I'd be inclined to do #3 before this.
> > >> > >
> > >> > > -Dan
> > >> > >
> > >> > > On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols <
> onich...@pivotal.io>
> > >> > wrote:
> > >> > >
> > >> > >> Goal:
> > >> > >>
> > >> > >> Run Geode on Java 11 (GEODE-3 <
> > >> > >> https://issues.apache.org/jira/browse/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 all usage of restricted APIs from all Geode code, and find
> > >> > >> replacements for all 3rd party libraries that depend on
> restricted
> > >> APIs.
> > >> > >>
> > >> > >> Solution #2:
> > >> > >>
> > >> > >> Adopt Java 11’s “Jigsaw" Module System and properly declare
> > >> dependencies
> > >> > >> on restricted APIs.
> > >> > >>
> > >> > >> Solution #3:
> > >> > >>
> > >> > >> Update all existing public and personal scripts, wrappers, IDE
> > >> > >> configurations, test harnesses, and other java invocations to
> add a
> > >> > handful
> > >> > >> of --add-opens flags to the java commandline to override the
> > default
> > >> > Java
> > >> > >> 11 restrictions.
> > >> > >>
> > >> > >> Solution #4:
> > >> > >>
> > >> > >> Use the MIT-licensed permit-reflect <
> > >> > >> https://github.com/nqzero/permit-reflect> library to
> > >> programmatically
> > >> > >> override Java 11’s API restrictions.
> > >> > >>
> > >> > >>
> > >> > >> In terms of feasibility:
> > >> > >> #1 would be extremely difficult.  Geode has a large number of
> > >> > dependencies
> > >> > >> on internal Java APIs in critical areas, and replacing them would
> > be
> > >> > >> time-consuming, potentially destabilizing, and very likely to
> > >> negatively
> > >> > >> impact performance.
> > >> > >> #2 is complex because we still need Geode to run on Java 8, so
> not
> > >> using
> > >> > >> any Java 11 features seems safer than introducing multi-version
> > jars,
> > >> > >> cross-compilation, or separate releases per target Java platform.
> > >> > >> #3 is easy enough to implement in scripts that are under source
> > >> control,
> > >> > >> but users or developers that have their own IDE configurations or
> > >> test
> > >> > >> environments may struggle to understand why they are getting
> errors
> > >> and
> > >> > how
> > >> > >> to fix them.
> > >> > >> #4 restores full Java8-like permissions with essentially just a
> > >> change
> > >> > to
> > >> > >> main() method.
> > >> > >>
> > >> > >>
> > 

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

[Sai Boorlagadda]

+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 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 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 allows this.
> >
> > On Wed, Oct 10, 2018 at 1:47 PM Jacob Barrett 
> wrote:
> >
> >> 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 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 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
> >> > > been around for about 1 month, has 0 tests in the source that I can
> >> see,
> >> > > and seems to be tripling down on relying on sun.misc.Unsafe to do
> >> stuff.
> >> > > I'd be inclined to do #3 before this.
> >> > >
> >> > > -Dan
> >> > >
> >> > > On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols 
> >> > wrote:
> >> > >
> >> > >> Goal:
> >> > >>
> >> > >> Run Geode on Java 11 (GEODE-3 <
> >> > >> https://issues.apache.org/jira/browse/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 all usage of restricted APIs from all Geode code, and find
> >> > >> replacements for all 3rd party libraries that depend on restricted
> >> APIs.
> >> > >>
> >> > >> Solution #2:
> >> > >>
> >> > >> Adopt Java 11’s “Jigsaw" Module System and properly declare
> >> dependencies
> >> > >> on restricted APIs.
> >> > >>
> >> > >> Solution #3:
> >> > >>
> >> > >> Update all existing public and personal scripts, wrappers, IDE
> >> > >> configurations, test harnesses, and other java invocations to add a
> >> > handful
> >> > >> of --add-opens flags to the java commandline to override the
> default
> >> > Java
> >> > >> 11 restrictions.
> >> > >>
> >> > >> Solution #4:
> >> > >>
> >> > >> Use the MIT-licensed permit-reflect <
> >> > >> https://github.com/nqzero/permit-reflect> library to
> >> programmatically
> >> > >> override Java 11’s API restrictions.
> >> > >>
> >> > >>
> >> > >> In terms of feasibility:
> >> > >> #1 would be extremely difficult.  Geode has a large number of
> >> > dependencies
> >> > >> on internal Java APIs in critical areas, and replacing them would
> be
> >> > >> time-consuming, potentially destabilizing, and very likely to
> >> negatively
> >> > >> impact performance.
> >> > >> #2 is complex because we still need Geode to run on Java 8, so not
> >> using
> >> > >> any Java 11 features seems safer than introducing multi-version
> jars,
> >> > >> cross-compilation, or separate releases per target Java platform.
> >> > >> #3 is easy enough to implement in scripts that are under source
> >> control,
> >> > >> but users or developers that have their own IDE configurations or
> >> test
> >> > >> environments may struggle to understand why they are getting errors
> >> and
> >> > how
> >> > >> to fix them.
> >> > >> #4 restores full Java8-like permissions with essentially just a
> >> change
> >> > to
> >> > >> main() method.
> >> > >>
> >> > >>
> >> > >> Which strategy do you prefer?  Java 11 test jobs are in the
> pipeline
> >> <
> >> > >> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop
> >
> >> as
> >> > of
> >> > >> today — let’s make them green!
> >> > >>
> >> > >>
> >> > >> -Owen
> >> >
> >> >
> >>
> >
>

Re: [DISCUSS] Java 11 jobs in the pipeline

[Alexander Murmann]

+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 spirit of keeping
> develop releasable, we should keep the main pipeline clean and only include
> what is releasable today in the pipeline.
>
> Thoughts?
> -Dan
>

[DISCUSS] Java 11 jobs in the pipeline

[Dan Smith]

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

[Galen O'Sullivan]

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 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 allows this.
>
> On Wed, Oct 10, 2018 at 1:47 PM Jacob Barrett  wrote:
>
>> 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 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 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
>> > > been around for about 1 month, has 0 tests in the source that I can
>> see,
>> > > and seems to be tripling down on relying on sun.misc.Unsafe to do
>> stuff.
>> > > I'd be inclined to do #3 before this.
>> > >
>> > > -Dan
>> > >
>> > > On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols 
>> > wrote:
>> > >
>> > >> Goal:
>> > >>
>> > >> Run Geode on Java 11 (GEODE-3 <
>> > >> https://issues.apache.org/jira/browse/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 all usage of restricted APIs from all Geode code, and find
>> > >> replacements for all 3rd party libraries that depend on restricted
>> APIs.
>> > >>
>> > >> Solution #2:
>> > >>
>> > >> Adopt Java 11’s “Jigsaw" Module System and properly declare
>> dependencies
>> > >> on restricted APIs.
>> > >>
>> > >> Solution #3:
>> > >>
>> > >> Update all existing public and personal scripts, wrappers, IDE
>> > >> configurations, test harnesses, and other java invocations to add a
>> > handful
>> > >> of --add-opens flags to the java commandline to override the default
>> > Java
>> > >> 11 restrictions.
>> > >>
>> > >> Solution #4:
>> > >>
>> > >> Use the MIT-licensed permit-reflect <
>> > >> https://github.com/nqzero/permit-reflect> library to
>> programmatically
>> > >> override Java 11’s API restrictions.
>> > >>
>> > >>
>> > >> In terms of feasibility:
>> > >> #1 would be extremely difficult.  Geode has a large number of
>> > dependencies
>> > >> on internal Java APIs in critical areas, and replacing them would be
>> > >> time-consuming, potentially destabilizing, and very likely to
>> negatively
>> > >> impact performance.
>> > >> #2 is complex because we still need Geode to run on Java 8, so not
>> using
>> > >> any Java 11 features seems safer than introducing multi-version jars,
>> > >> cross-compilation, or separate releases per target Java platform.
>> > >> #3 is easy enough to implement in scripts that are under source
>> control,
>> > >> but users or developers that have their own IDE configurations or
>> test
>> > >> environments may struggle to understand why they are getting errors
>> and
>> > how
>> > >> to fix them.
>> > >> #4 restores full Java8-like permissions with essentially just a
>> change
>> > to
>> > >> main() method.
>> > >>
>> > >>
>> > >> Which strategy do you prefer?  Java 11 test jobs are in the pipeline
>> <
>> > >> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop>
>> as
>> > of
>> > >> today — let’s make them green!
>> > >>
>> > >>
>> > >> -Owen
>> >
>> >
>>
>

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

[Galen O'Sullivan]

#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 allows this.

On Wed, Oct 10, 2018 at 1:47 PM Jacob Barrett  wrote:

> 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 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 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
> > > been around for about 1 month, has 0 tests in the source that I can
> see,
> > > and seems to be tripling down on relying on sun.misc.Unsafe to do
> stuff.
> > > I'd be inclined to do #3 before this.
> > >
> > > -Dan
> > >
> > > On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols 
> > wrote:
> > >
> > >> Goal:
> > >>
> > >> Run Geode on Java 11 (GEODE-3 <
> > >> https://issues.apache.org/jira/browse/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 all usage of restricted APIs from all Geode code, and find
> > >> replacements for all 3rd party libraries that depend on restricted
> APIs.
> > >>
> > >> Solution #2:
> > >>
> > >> Adopt Java 11’s “Jigsaw" Module System and properly declare
> dependencies
> > >> on restricted APIs.
> > >>
> > >> Solution #3:
> > >>
> > >> Update all existing public and personal scripts, wrappers, IDE
> > >> configurations, test harnesses, and other java invocations to add a
> > handful
> > >> of --add-opens flags to the java commandline to override the default
> > Java
> > >> 11 restrictions.
> > >>
> > >> Solution #4:
> > >>
> > >> Use the MIT-licensed permit-reflect <
> > >> https://github.com/nqzero/permit-reflect> library to programmatically
> > >> override Java 11’s API restrictions.
> > >>
> > >>
> > >> In terms of feasibility:
> > >> #1 would be extremely difficult.  Geode has a large number of
> > dependencies
> > >> on internal Java APIs in critical areas, and replacing them would be
> > >> time-consuming, potentially destabilizing, and very likely to
> negatively
> > >> impact performance.
> > >> #2 is complex because we still need Geode to run on Java 8, so not
> using
> > >> any Java 11 features seems safer than introducing multi-version jars,
> > >> cross-compilation, or separate releases per target Java platform.
> > >> #3 is easy enough to implement in scripts that are under source
> control,
> > >> but users or developers that have their own IDE configurations or test
> > >> environments may struggle to understand why they are getting errors
> and
> > how
> > >> to fix them.
> > >> #4 restores full Java8-like permissions with essentially just a change
> > to
> > >> main() method.
> > >>
> > >>
> > >> Which strategy do you prefer?  Java 11 test jobs are in the pipeline <
> > >> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop>
> as
> > of
> > >> today — let’s make them green!
> > >>
> > >>
> > >> -Owen
> >
> >
>

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

[Jacob Barrett]

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 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 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
> > been around for about 1 month, has 0 tests in the source that I can see,
> > and seems to be tripling down on relying on sun.misc.Unsafe to do stuff.
> > I'd be inclined to do #3 before this.
> >
> > -Dan
> >
> > On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols 
> wrote:
> >
> >> Goal:
> >>
> >> Run Geode on Java 11 (GEODE-3 <
> >> https://issues.apache.org/jira/browse/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 all usage of restricted APIs from all Geode code, and find
> >> replacements for all 3rd party libraries that depend on restricted APIs.
> >>
> >> Solution #2:
> >>
> >> Adopt Java 11’s “Jigsaw" Module System and properly declare dependencies
> >> on restricted APIs.
> >>
> >> Solution #3:
> >>
> >> Update all existing public and personal scripts, wrappers, IDE
> >> configurations, test harnesses, and other java invocations to add a
> handful
> >> of --add-opens flags to the java commandline to override the default
> Java
> >> 11 restrictions.
> >>
> >> Solution #4:
> >>
> >> Use the MIT-licensed permit-reflect <
> >> https://github.com/nqzero/permit-reflect> library to programmatically
> >> override Java 11’s API restrictions.
> >>
> >>
> >> In terms of feasibility:
> >> #1 would be extremely difficult.  Geode has a large number of
> dependencies
> >> on internal Java APIs in critical areas, and replacing them would be
> >> time-consuming, potentially destabilizing, and very likely to negatively
> >> impact performance.
> >> #2 is complex because we still need Geode to run on Java 8, so not using
> >> any Java 11 features seems safer than introducing multi-version jars,
> >> cross-compilation, or separate releases per target Java platform.
> >> #3 is easy enough to implement in scripts that are under source control,
> >> but users or developers that have their own IDE configurations or test
> >> environments may struggle to understand why they are getting errors and
> how
> >> to fix them.
> >> #4 restores full Java8-like permissions with essentially just a change
> to
> >> main() method.
> >>
> >>
> >> Which strategy do you prefer?  Java 11 test jobs are in the pipeline <
> >> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop> as
> of
> >> today — let’s make them green!
> >>
> >>
> >> -Owen
>
>

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

[Jacob Barrett]

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 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
> been around for about 1 month, has 0 tests in the source that I can see,
> and seems to be tripling down on relying on sun.misc.Unsafe to do stuff.
> I'd be inclined to do #3 before this.
> 
> -Dan
> 
> On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols  wrote:
> 
>> Goal:
>> 
>> Run Geode on Java 11 (GEODE-3 <
>> https://issues.apache.org/jira/browse/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 all usage of restricted APIs from all Geode code, and find
>> replacements for all 3rd party libraries that depend on restricted APIs.
>> 
>> Solution #2:
>> 
>> Adopt Java 11’s “Jigsaw" Module System and properly declare dependencies
>> on restricted APIs.
>> 
>> Solution #3:
>> 
>> Update all existing public and personal scripts, wrappers, IDE
>> configurations, test harnesses, and other java invocations to add a handful
>> of --add-opens flags to the java commandline to override the default Java
>> 11 restrictions.
>> 
>> Solution #4:
>> 
>> Use the MIT-licensed permit-reflect <
>> https://github.com/nqzero/permit-reflect> library to programmatically
>> override Java 11’s API restrictions.
>> 
>> 
>> In terms of feasibility:
>> #1 would be extremely difficult.  Geode has a large number of dependencies
>> on internal Java APIs in critical areas, and replacing them would be
>> time-consuming, potentially destabilizing, and very likely to negatively
>> impact performance.
>> #2 is complex because we still need Geode to run on Java 8, so not using
>> any Java 11 features seems safer than introducing multi-version jars,
>> cross-compilation, or separate releases per target Java platform.
>> #3 is easy enough to implement in scripts that are under source control,
>> but users or developers that have their own IDE configurations or test
>> environments may struggle to understand why they are getting errors and how
>> to fix them.
>> #4 restores full Java8-like permissions with essentially just a change to
>> main() method.
>> 
>> 
>> Which strategy do you prefer?  Java 11 test jobs are in the pipeline <
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop> as of
>> today — let’s make them green!
>> 
>> 
>> -Owen

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

[Anthony Baker]

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?  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 
>> ).
>> 
>> 
>> 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 all usage of restricted APIs from all Geode code, and find 
>> replacements for all 3rd party libraries that depend on restricted APIs.
>> 
>> Solution #2:
>> 
>> Adopt Java 11’s “Jigsaw" Module System and properly declare dependencies on 
>> restricted APIs.
>> 
>> Solution #3:
>> 
>> Update all existing public and personal scripts, wrappers, IDE 
>> configurations, test harnesses, and other java invocations to add a handful 
>> of --add-opens flags to the java commandline to override the default Java 11 
>> restrictions.
>> 
>> Solution #4:
>> 
>> Use the MIT-licensed permit-reflect 
>>  library to programmatically 
>> override Java 11’s API restrictions.
>> 
>> 
>> In terms of feasibility:
>> #1 would be extremely difficult.  Geode has a large number of dependencies 
>> on internal Java APIs in critical areas, and replacing them would be 
>> time-consuming, potentially destabilizing, and very likely to negatively 
>> impact performance.
>> #2 is complex because we still need Geode to run on Java 8, so not using any 
>> Java 11 features seems safer than introducing multi-version jars, 
>> cross-compilation, or separate releases per target Java platform.
>> #3 is easy enough to implement in scripts that are under source control, but 
>> users or developers that have their own IDE configurations or test 
>> environments may struggle to understand why they are getting errors and how 
>> to fix them.
>> #4 restores full Java8-like permissions with essentially just a change to 
>> main() method. 
>> 
>> 
>> Which strategy do you prefer?  Java 11 test jobs are in the pipeline 
>>  as of 
>> today — let’s make them green!
>> 
>> 
>> -Owen
> 

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

[Anthony Baker]

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 
> ).
> 
> 
> 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 all usage of restricted APIs from all Geode code, and find 
> replacements for all 3rd party libraries that depend on restricted APIs.
> 
> Solution #2:
> 
> Adopt Java 11’s “Jigsaw" Module System and properly declare dependencies on 
> restricted APIs.
> 
> Solution #3:
> 
> Update all existing public and personal scripts, wrappers, IDE 
> configurations, test harnesses, and other java invocations to add a handful 
> of --add-opens flags to the java commandline to override the default Java 11 
> restrictions.
> 
> Solution #4:
> 
> Use the MIT-licensed permit-reflect 
>  library to programmatically 
> override Java 11’s API restrictions.
> 
> 
> In terms of feasibility:
> #1 would be extremely difficult.  Geode has a large number of dependencies on 
> internal Java APIs in critical areas, and replacing them would be 
> time-consuming, potentially destabilizing, and very likely to negatively 
> impact performance.
> #2 is complex because we still need Geode to run on Java 8, so not using any 
> Java 11 features seems safer than introducing multi-version jars, 
> cross-compilation, or separate releases per target Java platform.
> #3 is easy enough to implement in scripts that are under source control, but 
> users or developers that have their own IDE configurations or test 
> environments may struggle to understand why they are getting errors and how 
> to fix them.
> #4 restores full Java8-like permissions with essentially just a change to 
> main() method. 
> 
> 
> Which strategy do you prefer?  Java 11 test jobs are in the pipeline 
>  as of 
> today — let’s make them green!
> 
> 
> -Owen

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

[Dan Smith]

#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
been around for about 1 month, has 0 tests in the source that I can see,
and seems to be tripling down on relying on sun.misc.Unsafe to do stuff.
I'd be inclined to do #3 before this.

-Dan

On Wed, Oct 10, 2018 at 12:20 PM Owen Nichols  wrote:

> Goal:
>
> Run Geode on Java 11 (GEODE-3 <
> https://issues.apache.org/jira/browse/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 all usage of restricted APIs from all Geode code, and find
> replacements for all 3rd party libraries that depend on restricted APIs.
>
> Solution #2:
>
> Adopt Java 11’s “Jigsaw" Module System and properly declare dependencies
> on restricted APIs.
>
> Solution #3:
>
> Update all existing public and personal scripts, wrappers, IDE
> configurations, test harnesses, and other java invocations to add a handful
> of --add-opens flags to the java commandline to override the default Java
> 11 restrictions.
>
> Solution #4:
>
> Use the MIT-licensed permit-reflect <
> https://github.com/nqzero/permit-reflect> library to programmatically
> override Java 11’s API restrictions.
>
>
> In terms of feasibility:
> #1 would be extremely difficult.  Geode has a large number of dependencies
> on internal Java APIs in critical areas, and replacing them would be
> time-consuming, potentially destabilizing, and very likely to negatively
> impact performance.
> #2 is complex because we still need Geode to run on Java 8, so not using
> any Java 11 features seems safer than introducing multi-version jars,
> cross-compilation, or separate releases per target Java platform.
> #3 is easy enough to implement in scripts that are under source control,
> but users or developers that have their own IDE configurations or test
> environments may struggle to understand why they are getting errors and how
> to fix them.
> #4 restores full Java8-like permissions with essentially just a change to
> main() method.
>
>
>  Which strategy do you prefer?  Java 11 test jobs are in the pipeline <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop> as of
> today — let’s make them green!
>
>
> -Owen

Re: Concourse upgrade

[Bruce Schuchardt]

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 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: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

[Robert Houghton]

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 proven otherwise


On Oct 10, 2018 12:20, "Owen Nichols"  wrote:

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 all usage of restricted APIs from all Geode code, and find
replacements for all 3rd party libraries that depend on restricted APIs.

Solution #2:

Adopt Java 11’s “Jigsaw" Module System and properly declare dependencies on
restricted APIs.

Solution #3:

Update all existing public and personal scripts, wrappers, IDE
configurations, test harnesses, and other java invocations to add a handful
of --add-opens flags to the java commandline to override the default Java
11 restrictions.

Solution #4:

Use the MIT-licensed permit-reflect <
https://github.com/nqzero/permit-reflect> library to programmatically
override Java 11’s API restrictions.


In terms of feasibility:
#1 would be extremely difficult.  Geode has a large number of dependencies
on internal Java APIs in critical areas, and replacing them would be
time-consuming, potentially destabilizing, and very likely to negatively
impact performance.
#2 is complex because we still need Geode to run on Java 8, so not using
any Java 11 features seems safer than introducing multi-version jars,
cross-compilation, or separate releases per target Java platform.
#3 is easy enough to implement in scripts that are under source control,
but users or developers that have their own IDE configurations or test
environments may struggle to understand why they are getting errors and how
to fix them.
#4 restores full Java8-like permissions with essentially just a change to
main() method.


 Which strategy do you prefer?  Java 11 test jobs are in the pipeline <
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop> as of
today — let’s make them green!



-Owen

Re: Geode Native & Apache Geode 1.8 Release

[Anilkumar Gingade]

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
geode releases.

-Anil.



On Wed, Oct 10, 2018 at 12:02 PM Ernest Burghardt 
wrote:

> +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] https://issues.apache.org/jira/browse/GEODE-1416
> >
> >
> > > On Oct 10, 2018, at 11:52 AM, Dan Smith  wrote:
> > >
> > > 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?
> > > - How do we verify the NC code - can we create a public pipeline?
> > >
> > > Shipping these native APIs will be a great improvement!
> > >
> > > -Dan
> > >
> > > On Wed, Oct 10, 2018 at 8:41 AM Addison Huddy 
> wrote:
> > >
> > >> 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 donation, the project has
> > >>
> > >>   - modernized its C++ API based on C++ 11 standards
> > >>   - refactored away the cache singleton to allow for more flexible
> > >>   architectures and client-side data modeling
> > >>   - refactored the serializable interfaces (DataSerializable,
> > >>   PdxSerializable, DataSerializableFixedId) to make object
> serialization
> > >>   more straight-forward
> > >>   - created several examples on how to use the client (
> > >>   https://github.com/apache/geode-native/tree/develop/examples)
> > >>
> > >> In all, the project has closed 285 JIRA tickets since donation.
> > >>
> > >> If you want to learn more about the Geode Native, check out these two
> > >> Apache Geode By Example videos.
> > >>
> > >> .NET: https://www.youtube.com/watch?v=-LQYNJNQ7B4=3s
> > >>
> > >> C++: https://www.youtube.com/watch?v=KJciEcFRdtY=1s
> > >>
> > >> Looking forward to hearing your input on including the first cut of
> > Geode
> > >> Native in Apache Geode 1.8.
> > >>
> > >>
> > >> Best,
> > >> Addison
> > >>
> >
> >
>

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

[Owen Nichols]

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 all usage of restricted APIs from all Geode code, and find replacements 
for all 3rd party libraries that depend on restricted APIs.

Solution #2:

Adopt Java 11’s “Jigsaw" Module System and properly declare dependencies on 
restricted APIs.

Solution #3:

Update all existing public and personal scripts, wrappers, IDE configurations, 
test harnesses, and other java invocations to add a handful of --add-opens 
flags to the java commandline to override the default Java 11 restrictions.

Solution #4:

Use the MIT-licensed permit-reflect  
library to programmatically override Java 11’s API restrictions.


In terms of feasibility:
#1 would be extremely difficult.  Geode has a large number of dependencies on 
internal Java APIs in critical areas, and replacing them would be 
time-consuming, potentially destabilizing, and very likely to negatively impact 
performance.
#2 is complex because we still need Geode to run on Java 8, so not using any 
Java 11 features seems safer than introducing multi-version jars, 
cross-compilation, or separate releases per target Java platform.
#3 is easy enough to implement in scripts that are under source control, but 
users or developers that have their own IDE configurations or test environments 
may struggle to understand why they are getting errors and how to fix them.
#4 restores full Java8-like permissions with essentially just a change to 
main() method. 


 Which strategy do you prefer?  Java 11 test jobs are in the pipeline 
 as of 
today — let’s make them green!


-Owen

Re: Geode Native & Apache Geode 1.8 Release

[Ernest Burghardt]

+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] https://issues.apache.org/jira/browse/GEODE-1416
>
>
> > On Oct 10, 2018, at 11:52 AM, Dan Smith  wrote:
> >
> > 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?
> > - How do we verify the NC code - can we create a public pipeline?
> >
> > Shipping these native APIs will be a great improvement!
> >
> > -Dan
> >
> > On Wed, Oct 10, 2018 at 8:41 AM Addison Huddy  wrote:
> >
> >> 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 donation, the project has
> >>
> >>   - modernized its C++ API based on C++ 11 standards
> >>   - refactored away the cache singleton to allow for more flexible
> >>   architectures and client-side data modeling
> >>   - refactored the serializable interfaces (DataSerializable,
> >>   PdxSerializable, DataSerializableFixedId) to make object serialization
> >>   more straight-forward
> >>   - created several examples on how to use the client (
> >>   https://github.com/apache/geode-native/tree/develop/examples)
> >>
> >> In all, the project has closed 285 JIRA tickets since donation.
> >>
> >> If you want to learn more about the Geode Native, check out these two
> >> Apache Geode By Example videos.
> >>
> >> .NET: https://www.youtube.com/watch?v=-LQYNJNQ7B4=3s
> >>
> >> C++: https://www.youtube.com/watch?v=KJciEcFRdtY=1s
> >>
> >> Looking forward to hearing your input on including the first cut of
> Geode
> >> Native in Apache Geode 1.8.
> >>
> >>
> >> Best,
> >> Addison
> >>
>
>

Re: Geode Native & Apache Geode 1.8 Release

[Anthony Baker]

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:
> 
> 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?
> - How do we verify the NC code - can we create a public pipeline?
> 
> Shipping these native APIs will be a great improvement!
> 
> -Dan
> 
> On Wed, Oct 10, 2018 at 8:41 AM Addison Huddy  wrote:
> 
>> 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 donation, the project has
>> 
>>   - modernized its C++ API based on C++ 11 standards
>>   - refactored away the cache singleton to allow for more flexible
>>   architectures and client-side data modeling
>>   - refactored the serializable interfaces (DataSerializable,
>>   PdxSerializable, DataSerializableFixedId) to make object serialization
>>   more straight-forward
>>   - created several examples on how to use the client (
>>   https://github.com/apache/geode-native/tree/develop/examples)
>> 
>> In all, the project has closed 285 JIRA tickets since donation.
>> 
>> If you want to learn more about the Geode Native, check out these two
>> Apache Geode By Example videos.
>> 
>> .NET: https://www.youtube.com/watch?v=-LQYNJNQ7B4=3s
>> 
>> C++: https://www.youtube.com/watch?v=KJciEcFRdtY=1s
>> 
>> Looking forward to hearing your input on including the first cut of Geode
>> Native in Apache Geode 1.8.
>> 
>> 
>> Best,
>> Addison
>> 

Re: Geode Native & Apache Geode 1.8 Release

[Dan Smith]

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?
 - How do we verify the NC code - can we create a public pipeline?

Shipping these native APIs will be a great improvement!

-Dan

On Wed, Oct 10, 2018 at 8:41 AM Addison Huddy  wrote:

> 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 donation, the project has
>
>- modernized its C++ API based on C++ 11 standards
>- refactored away the cache singleton to allow for more flexible
>architectures and client-side data modeling
>- refactored the serializable interfaces (DataSerializable,
>PdxSerializable, DataSerializableFixedId) to make object serialization
>more straight-forward
>- created several examples on how to use the client (
>https://github.com/apache/geode-native/tree/develop/examples)
>
> In all, the project has closed 285 JIRA tickets since donation.
>
> If you want to learn more about the Geode Native, check out these two
> Apache Geode By Example videos.
>
> .NET: https://www.youtube.com/watch?v=-LQYNJNQ7B4=3s
>
> C++: https://www.youtube.com/watch?v=KJciEcFRdtY=1s
>
> Looking forward to hearing your input on including the first cut of Geode
> Native in Apache Geode 1.8.
>
>
> Best,
> Addison
>

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

[Jared Stewart]

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 we
have previously released in patch versions).  Moreover, the introduction of
"substantial new functionality or improvments" is a *sufficient* condition
for incrementing minor versions, but is not a *necessary* condition.  For
these reasons, I vote +1 to aim for quarterly at-least-minor releases.

On Wed, Oct 10, 2018 at 11:17 AM Bruce Schuchardt 
wrote:

> 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 actually any functional changes.  We should change those
> definitions to match what we're actually doing.
>
>
> On 10/10/18 9:35 AM, Anthony Baker wrote:
> > 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]
> https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching
> >
> >
> >> On Oct 10, 2018, at 8:44 AM, Ryan McMahon 
> wrote:
> >>
> >> 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 patch release.  I personally prefer SemVer’s definition, but
> it’s
> >> up for debate.
> >>
> >> Perhaps we can do 3-month release cycles, and determine whether the
> release
> >> would be patch or minor based on the changes added since the last
> release
> >> (bug fixes vs new functionality).
> >>
> >> Ryan
>
>

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

[Bruce Schuchardt]

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 actually any functional changes.  We should change those 
definitions to match what we're actually doing.



On 10/10/18 9:35 AM, Anthony Baker wrote:

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] https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching



On Oct 10, 2018, at 8:44 AM, Ryan McMahon  wrote:

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 patch release.  I personally prefer SemVer’s definition, but it’s
up for debate.

Perhaps we can do 3-month release cycles, and determine whether the release
would be patch or minor based on the changes added since the last release
(bug fixes vs new functionality).

Ryan

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

[Anthony Baker]

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, how can you say never? Didn't we just go through a time like
> this?
> 
> On Wed, Oct 10, 2018, 10:29 Alexander Murmann  wrote:
> 
>> 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 for a
>> patch or major, this would likely impact our branching strategy. Breaking
>> changes would be permitted for a major and we'd need to think about how to
>> work with a support branch for the previous major etc. If we aimed for a
>> patch we couldn't merge features, etc.

Concourse upgrade

[Sean Goller]

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

[Sai Boorlagadda]

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 
wrote:

> 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 for a
> patch or major, this would likely impact our branching strategy. Breaking
> changes would be permitted for a major and we'd need to think about how to
> work with a support branch for the previous major etc. If we aimed for a
> patch we couldn't merge features, etc.
>
> On Wed, Oct 10, 2018 at 10:17 AM Sai Boorlagadda <
> sai.boorlaga...@gmail.com>
> wrote:
>
> > 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 not be configured as
> > *maintenance* changes.  Minor releases can also
> > > be increased if extensions or sub-projects add new features or are
> > updated somehow.
> >
> > On Wed, Oct 10, 2018 at 9:35 AM Anthony Baker  wrote:
> >
> > > 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]
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching
> > >
> > >
> > > > On Oct 10, 2018, at 8:44 AM, Ryan McMahon 
> > > wrote:
> > > >
> > > > 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 patch release.  I personally prefer SemVer’s definition,
> but
> > > it’s
> > > > up for debate.
> > > >
> > > > Perhaps we can do 3-month release cycles, and determine whether the
> > > release
> > > > would be patch or minor based on the changes added since the last
> > release
> > > > (bug fixes vs new functionality).
> > > >
> > > > Ryan
> > >
> > >
> >
>

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

[Alexander Murmann]

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 for a
patch or major, this would likely impact our branching strategy. Breaking
changes would be permitted for a major and we'd need to think about how to
work with a support branch for the previous major etc. If we aimed for a
patch we couldn't merge features, etc.

On Wed, Oct 10, 2018 at 10:17 AM Sai Boorlagadda 
wrote:

> 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 not be configured as
> *maintenance* changes.  Minor releases can also
> > be increased if extensions or sub-projects add new features or are
> updated somehow.
>
> On Wed, Oct 10, 2018 at 9:35 AM Anthony Baker  wrote:
>
> > 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]
> >
> https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching
> >
> >
> > > On Oct 10, 2018, at 8:44 AM, Ryan McMahon 
> > wrote:
> > >
> > > 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 patch release.  I personally prefer SemVer’s definition, but
> > it’s
> > > up for debate.
> > >
> > > Perhaps we can do 3-month release cycles, and determine whether the
> > release
> > > would be patch or minor based on the changes added since the last
> release
> > > (bug fixes vs new functionality).
> > >
> > > Ryan
> >
> >
>

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

[Sai Boorlagadda]

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 not be configured as
*maintenance* changes.  Minor releases can also
> be increased if extensions or sub-projects add new features or are
updated somehow.

On Wed, Oct 10, 2018 at 9:35 AM Anthony Baker  wrote:

> 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]
> https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching
>
>
> > On Oct 10, 2018, at 8:44 AM, Ryan McMahon 
> wrote:
> >
> > 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 patch release.  I personally prefer SemVer’s definition, but
> it’s
> > up for debate.
> >
> > Perhaps we can do 3-month release cycles, and determine whether the
> release
> > would be patch or minor based on the changes added since the last release
> > (bug fixes vs new functionality).
> >
> > Ryan
>
>

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

[Dave Barnes]

+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 leapfrog a year's worth of releases at one
go, or will they have to step through a chain of consecutive releases
one-by-one?
Or is that simply not an issue in an open source context?

On Wed, Oct 10, 2018 at 9:35 AM Anthony Baker  wrote:

> 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]
> https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching
>
>
> > On Oct 10, 2018, at 8:44 AM, Ryan McMahon 
> wrote:
> >
> > 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 patch release.  I personally prefer SemVer’s definition, but
> it’s
> > up for debate.
> >
> > Perhaps we can do 3-month release cycles, and determine whether the
> release
> > would be patch or minor based on the changes added since the last release
> > (bug fixes vs new functionality).
> >
> > Ryan
>
>

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

[Anthony Baker]

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] https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching


> On Oct 10, 2018, at 8:44 AM, Ryan McMahon  wrote:
> 
> 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 patch release.  I personally prefer SemVer’s definition, but it’s
> up for debate.
> 
> Perhaps we can do 3-month release cycles, and determine whether the release
> would be patch or minor based on the changes added since the last release
> (bug fixes vs new functionality).
> 
> Ryan

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

[Ryan McMahon]

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 patch release.  I personally prefer SemVer’s definition, but it’s
up for debate.

Perhaps we can do 3-month release cycles, and determine whether the release
would be patch or minor based on the changes added since the last release
(bug fixes vs new functionality).

Ryan

On Wed, Oct 10, 2018 at 7:48 AM Addison Huddy  wrote:

> +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 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 definitions before we make a
> > decision on schedule.
> >
> > On Tue, Oct 9, 2018 at 10:06 AM Alexander Murmann 
> > wrote:
> >
> > > Bruce, agreed. I think we should eliminate all the fluff language
> around
> > > "significant improvements". What's "significant" is entirely
> subjective.
> > > I'd prefer to stick to the much simpler definition from semver.org:
> > > >
> > > > Given a version number MAJOR.MINOR.PATCH, increment the:
> > > >
> > > >1. MAJOR version when you make incompatible API changes,
> > > >2. MINOR version when you add functionality in a
> > backwards-compatible
> > > >manner, and
> > > >3. PATCH version when you make backwards-compatible bug fixes.
> > > >
> > > >
> > > On Tue, Oct 9, 2018 at 9:03 AM Bruce Schuchardt <
> bschucha...@pivotal.io>
> > > wrote:
> > >
> > > > -1
> > > >
> > > > To me the definition of major vs minor releases is too muddy.  Our
> > > > Versioning and Branching
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching
> > > >
> > > >
> > > > page has requirements for a Minor release that seem orthogonal to
> this
> > > > discussion.  A Minor release "must definitely include significant
> > > > improvements to current API or components that justify not be
> > configured
> > > > (sic) as /maintenance/ changes".
> > > >
> > > > The page also describes a Maintenance release that seems to be more
> > what
> > > > we're talking about here.
> > > >
> > > > I think we need a new proposal for Major / Minor / Maintenance
> release
> > > > definitions.  That's what we should be voting on.
> > > >
> > > >
> > > >
> > > > On 10/8/18 2:24 PM, Alexander Murmann wrote:
> > > > > Hi everyone,
> > > > >
> > > > > As discussed in "Predictable minor release cadence", I'd like us to
> > > find
> > > > > agreement on releasing a new minor version every three months.
> There
> > > are
> > > > > more details in the other thread and I should have captured
> > everything
> > > > > relevant on the wiki:
> > > > > https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule
> > > > >
> > > > > There are also some discussions about patch releases. Let's please
> > > focus
> > > > > this vote on the proposed minor release schedule and carry on other
> > > > > discussions in the [DISCUSS] thread.
> > > > >
> > > > > Thank you all!
> > > > >
> > > >
> > > >
> > >
> >
>

Geode Native & Apache Geode 1.8 Release

[Addison Huddy]

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 donation, the project has

   - modernized its C++ API based on C++ 11 standards
   - refactored away the cache singleton to allow for more flexible
   architectures and client-side data modeling
   - refactored the serializable interfaces (DataSerializable,
   PdxSerializable, DataSerializableFixedId) to make object serialization
   more straight-forward
   - created several examples on how to use the client (
   https://github.com/apache/geode-native/tree/develop/examples)

In all, the project has closed 285 JIRA tickets since donation.

If you want to learn more about the Geode Native, check out these two
Apache Geode By Example videos.

.NET: https://www.youtube.com/watch?v=-LQYNJNQ7B4=3s

C++: https://www.youtube.com/watch?v=KJciEcFRdtY=1s

Looking forward to hearing your input on including the first cut of Geode
Native in Apache Geode 1.8.


Best,
Addison

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

[Addison Huddy]

+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 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 definitions before we make a
> decision on schedule.
>
> On Tue, Oct 9, 2018 at 10:06 AM Alexander Murmann 
> wrote:
>
> > Bruce, agreed. I think we should eliminate all the fluff language around
> > "significant improvements". What's "significant" is entirely subjective.
> > I'd prefer to stick to the much simpler definition from semver.org:
> > >
> > > Given a version number MAJOR.MINOR.PATCH, increment the:
> > >
> > >1. MAJOR version when you make incompatible API changes,
> > >2. MINOR version when you add functionality in a
> backwards-compatible
> > >manner, and
> > >3. PATCH version when you make backwards-compatible bug fixes.
> > >
> > >
> > On Tue, Oct 9, 2018 at 9:03 AM Bruce Schuchardt 
> > wrote:
> >
> > > -1
> > >
> > > To me the definition of major vs minor releases is too muddy.  Our
> > > Versioning and Branching
> > > <
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching
> > >
> > >
> > > page has requirements for a Minor release that seem orthogonal to this
> > > discussion.  A Minor release "must definitely include significant
> > > improvements to current API or components that justify not be
> configured
> > > (sic) as /maintenance/ changes".
> > >
> > > The page also describes a Maintenance release that seems to be more
> what
> > > we're talking about here.
> > >
> > > I think we need a new proposal for Major / Minor / Maintenance release
> > > definitions.  That's what we should be voting on.
> > >
> > >
> > >
> > > On 10/8/18 2:24 PM, Alexander Murmann wrote:
> > > > Hi everyone,
> > > >
> > > > As discussed in "Predictable minor release cadence", I'd like us to
> > find
> > > > agreement on releasing a new minor version every three months. There
> > are
> > > > more details in the other thread and I should have captured
> everything
> > > > relevant on the wiki:
> > > > https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule
> > > >
> > > > There are also some discussions about patch releases. Let's please
> > focus
> > > > this vote on the proposed minor release schedule and carry on other
> > > > discussions in the [DISCUSS] thread.
> > > >
> > > > Thank you all!
> > > >
> > >
> > >
> >
>

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

[Sai Boorlagadda]

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 definitions before we make a
decision on schedule.

On Tue, Oct 9, 2018 at 10:06 AM Alexander Murmann 
wrote:

> Bruce, agreed. I think we should eliminate all the fluff language around
> "significant improvements". What's "significant" is entirely subjective.
> I'd prefer to stick to the much simpler definition from semver.org:
> >
> > Given a version number MAJOR.MINOR.PATCH, increment the:
> >
> >1. MAJOR version when you make incompatible API changes,
> >2. MINOR version when you add functionality in a backwards-compatible
> >manner, and
> >3. PATCH version when you make backwards-compatible bug fixes.
> >
> >
> On Tue, Oct 9, 2018 at 9:03 AM Bruce Schuchardt 
> wrote:
>
> > -1
> >
> > To me the definition of major vs minor releases is too muddy.  Our
> > Versioning and Branching
> > <
> >
> https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching
> >
> >
> > page has requirements for a Minor release that seem orthogonal to this
> > discussion.  A Minor release "must definitely include significant
> > improvements to current API or components that justify not be configured
> > (sic) as /maintenance/ changes".
> >
> > The page also describes a Maintenance release that seems to be more what
> > we're talking about here.
> >
> > I think we need a new proposal for Major / Minor / Maintenance release
> > definitions.  That's what we should be voting on.
> >
> >
> >
> > On 10/8/18 2:24 PM, Alexander Murmann wrote:
> > > Hi everyone,
> > >
> > > As discussed in "Predictable minor release cadence", I'd like us to
> find
> > > agreement on releasing a new minor version every three months. There
> are
> > > more details in the other thread and I should have captured everything
> > > relevant on the wiki:
> > > https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule
> > >
> > > There are also some discussions about patch releases. Let's please
> focus
> > > this vote on the proposed minor release schedule and carry on other
> > > discussions in the [DISCUSS] thread.
> > >
> > > Thank you all!
> > >
> >
> >
>