>
> @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
@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
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
+1 on cutting in Nov.
Seems like community could benefit from one more release this year.
--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Oct 5, 2018 8:45 AM, "Anthony Baker" wrote:
> I’ve been advocating for a fixed release schedule for a long time. 3
> mont
+1 to a regular cadence and starting with a 3-month cadence. As we learned
earlier this year, monthly was too frequent to support our testing cycles
and for users to update.
On Fri, Oct 5, 2018 at 11:54 AM, Robert Houghton
wrote:
> +1 to Dan
>
> On Fri, Oct 5, 2018, 09:27 Dan Smith wrote:
>
> >
+1 to Dan
On Fri, Oct 5, 2018, 09:27 Dan Smith wrote:
> Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> I'm fine with that plan, as long as we can stick to only putting critical
> fixes on the release branch. Once the release branch is cut, it ships
> without further
If we go with more frequent releases, the number of available releases will
ramp up quickly.
What would be the best policy regarding earlier releases?
The Geode website's Release page currently links to 1.7.0, 1.6.0, 1.5.0,
and 1.4.0.
Would it be prudent to adopt a policy (as suggested by Craig Rus
+1 to releasing on a 3-month schedule and cutting the branch a month before the
release.
I’ve always felt that releasing based on content tends to prolong the
test/release cycle. Some features are held up from getting released due to
waiting for other features to be completed. Releasing on a re
Ok, I buy your arguments to cut the release branch 1 month ahead of time.
I'm fine with that plan, as long as we can stick to only putting critical
fixes on the release branch. Once the release branch is cut, it ships
without further changes unless we find new issues.
-Dan
On Fri, Oct 5, 2018 at
Robert and Sai, I think either release process can be stressful if your
team doesn't understand that there is no faster button, but that the only
lever is to cut scope (you can also compromise quality, but let's not do
that).
In either scenario there can be release pressure. To me the biggest
diffe
I’ve been advocating for a fixed release schedule for a long time. 3 months
seems like a good rate given the release overhead.
+1 on cutting the next release branch in November and shooting for an early
December v1.8.0 release.
Anthony
> On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda wrote:
>
I agree with Robert that we should release based on features that go in.
I am not sure if Apache Kafka & Spark are a good reference for GEODE.
These tools were evolving rapidly in the last couple of years and frequent
releases would be good for a growing community.
Should we do a patch release ev
I have found it refreshing that the geode released cadence has been based
on features being done, rather than a set schedule.
I come from an environment where we had quarterly releases and monthly
patches to all supported previous releases, and I can tell you that it
became a grind. That being sa
+1 for scheduled releases and cutting the branch one month prior to
release. Given the time it took to fully root out, classify, and solve
issues with this 1.7 release, I think a month is the right amount of time
between cutting the branch and releasing. If it ends up being too much or
too little,
Anil, releasing every 3 months should give us 3 months of dev work. Don't
forget that there will be one month during which the next release is
already cut, but the vast majority of the work is going to the release
after that. So while we cut 1.7 one month ago and release 1.7 today, we
already have
If I remember from earlier discussion; the plan was to deliver a release
once 3 months. But from the past release history we had difficulty in
achieving that, either the features are not completely ready or the
bug-fixes have taken more time. We need verify what is right for Apache
Geode, 3, 4 or 6
+1 on the scheduled release and also on one month prior to release we cut
the branch.
@Dan I feel keeping a one month will give a very comfortable time frame to
test + retest the release branch and we will be releasing a stable release
candidate.
For 1.7.0, it did take a month from cutting the br
+1 I definitely like the idea of scheduled releases.
I wonder if cutting the release branch a month ahead of time is overkill,
but I guess we do seem to keep finding issues after the branch is cut.
-Dan
On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann
wrote:
> Hi everyone,
>
> I want to propos
21 matches
Mail list logo
