+1 Quarterly releases
--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Oct 8, 2018 6:52 PM, "Sai Boorlagadda" wrote:
> +1 for time-based minors (if patches are reserved for security fixes)
>
> On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker wrote:
>
> > We reserv
---
Spring Data GemFire > Nightly-ApacheGeode > #1064 was successful.
---
Scheduled
2458 tests in total.
https://build.spring.io/browse/SGF-NAG-1064/
--
Thi
+1 for time-based minors (if patches are reserved for security fixes)
On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker wrote:
> We reserve the patch version number for when we want to issue a fix for a
> security vulnerability or address a critical bug. We did that with 1.1.1
> and 1.2.1.
>
> I thi
+1 for time-based releases.
I think we would do well to gain some discipline around releasing on a
predictable cadence. We're probably never going to be short on changes that
are 'worthy' of going out on a release which, too often, simply lead to the
release being stretched out as we add in Just O
We reserve the patch version number for when we want to issue a fix for a
security vulnerability or address a critical bug. We did that with 1.1.1 and
1.2.1.
I think the release schedule and SemVer are separate topics. AFAICT this
proposal is just about putting a more deterministic schedule a
On Mon, Oct 8, 2018 at 2:45 PM Udo Kohlmeyer wrote:
> Should this not rather be a statement of.. "Running on JDK 11+" and not
> 9+? Given that 9 + 10 are not in support anymore.
> Also, when this is released, we will running on 11 rather than 9, or
> what is the thought (end goal) with this effor
-0
It seems we have completely disregarded the *patch* version number. Does
this mean Geode versions will be *major*,*minor*? Can we then remove the
*patch* version on the release version?
In addition to this, should the test coverage not be sufficient enough
to allow "release when green"? I
+0
My preference would be for
- time-based patches and
- scope based minors & majors
On Mon, Oct 8, 2018 at 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 month
+1
On Mon, Oct 8, 2018 at 2:27 PM Jacob Barrett wrote:
> +0
>
> My preference is to release when there is something worth releasing rather
> than arbitrary points in time but I don't hold that preference strongly
> enough to spike this effort.
>
> On Mon, Oct 8, 2018 at 2:24 PM Alexander Murmann
+0
My preference is to release when there is something worth releasing rather
than arbitrary points in time but I don't hold that preference strongly
enough to spike this effort.
On Mon, Oct 8, 2018 at 2:24 PM Alexander Murmann
wrote:
> Hi everyone,
>
> As discussed in "Predictable minor releas
>
> @Alexander, I don't believe that we can use the "DISCUSS" thread to have
> made a decision that we are going to do something.
>
We can and we should use DISCUSS threads to make decisions.
The only things that actually need votes are releases and new
committers/pmc members. Nothing else should
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/GE
Should this not rather be a statement of.. "Running on JDK 11+" and not
9+? Given that 9 + 10 are not in support anymore.
Also, when this is released, we will running on 11 rather than 9, or
what is the thought (end goal) with this effort?
Also does this effort cover some of the main additions
@Alexander, I don't believe that we can use the "DISCUSS" thread to have
made a decision that we are going to do something.
Imo, it gauges interest rather than making a decision.
I would rather see the "VOTE" thread to be started, detailing the
proposal and process how this will work. As I don
In the effort of making GEODE java 9+ compatible, we already determined
that older released versions of GEODE can NOT be run using jdk9+. With this
in mind, should we still run those compatibility/upgrade DUnit tests in
java9+ pipeline? The current state of things are:
1) A subset of compatibility
Hi all,
Given the overwhelmingly positive response, I added a release schedule page
to the wiki:
https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule
Given the many "+1"s in this thread, can this be seen as agreed or do we
need a formal [VOTE] thread?
On Mon, Oct 8, 2018 at 1:34 PM
It’s an ASF requirement that PMC’s shepherd releases through a prescribed set
of practices. It doesn’t matter if a release is major, minor, or patch—they
all must be voted and approved the the PMC.
Anthony
> On Oct 8, 2018, at 1:04 PM, John Blum wrote:
>
> Also, a huge +1 to Ken's suggestio
+1; a time-based approach also helps to keep scope in check (i.e. smaller
changes and change sets), which leads to faster feedback (either fail
faster, sooner or find out you are on the right track), and shows
users/customers active progress/forward momentum, which is only a good
thing.
Also, a hu
+1,
It's important to keep in mind, we are talking fixed time releases and not
scoped releases. That means we have to be comfortable with the fact that
some features wont make it in a release even though they might be just
about to finish. Downstream products that use Geode need this
predictabilit
Awesome work!!
I've previously attempted to remove the deprecated LogWriterI18n.. but
did ran out of time..
--Udo
On 10/8/18 11:20, Bruce Schuchardt wrote:
Removal of LogWriterI18n is in JIRA:
https://issues.apache.org/jira/browse/GEODE-258
That's a subtask of GEODE-72
On 10/5/18 3:38 P
Removal of LogWriterI18n is in JIRA:
https://issues.apache.org/jira/browse/GEODE-258
That's a subtask of GEODE-72
On 10/5/18 3:38 PM, Jacob Barrett wrote:
Perhaps it would be wise to create a JIRA that lists things, like this, we
would like to remove from the public API come 2.0 so we don’t
21 matches
Mail list logo
