You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apex.apache.org by th...@apache.org on 2017/05/07 18:12:13 UTC
apex-site git commit: from 70e94c7532e7297da1e154178c28f911e8aa8098
Repository: apex-site
Updated Branches:
refs/heads/asf-site 4ad0ffad8 -> 76000d5fc
from 70e94c7532e7297da1e154178c28f911e8aa8098
Project: http://git-wip-us.apache.org/repos/asf/apex-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/apex-site/commit/76000d5f
Tree: http://git-wip-us.apache.org/repos/asf/apex-site/tree/76000d5f
Diff: http://git-wip-us.apache.org/repos/asf/apex-site/diff/76000d5f
Branch: refs/heads/asf-site
Commit: 76000d5fc0faee67ca6985acd9cfc41aa40927fb
Parents: 4ad0ffa
Author: Apex Dev <de...@apex.apache.org>
Authored: Sun May 7 11:12:05 2017 -0700
Committer: Thomas Weise <th...@apache.org>
Committed: Sun May 7 11:12:05 2017 -0700
----------------------------------------------------------------------
content/downloads.html | 8 +++---
content/release.html | 12 +++++----
content/roadmap.html | 57 +-----------------------------------------
content/verification.html | 4 +--
4 files changed, 14 insertions(+), 67 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/apex-site/blob/76000d5f/content/downloads.html
----------------------------------------------------------------------
diff --git a/content/downloads.html b/content/downloads.html
index 6d7b2bc..d7e4ca9 100644
--- a/content/downloads.html
+++ b/content/downloads.html
@@ -111,7 +111,7 @@
<span class="latest-tag">(latest)</span>
</td>
<td>
- 2017-05-05
+ 2017-05-04
</td>
<td>
<a href="http://www.apache.org/dyn/closer.lua/apex/apache-apex-core-3.6.0/apache-apex-core-3.6.0-source-release.zip">apex-3.6.0-source-release.zip</a><br>
@@ -193,7 +193,7 @@
<span class="latest-tag">(latest)</span>
</td>
<td>
- 2017-04-01
+ 2017-03-31
</td>
<td>
<a href="http://www.apache.org/dyn/closer.lua/apex/apache-apex-malhar-3.7.0/apache-apex-malhar-3.7.0-source-release.zip">malhar-3.7.0-source-release.zip</a><br>
@@ -226,7 +226,7 @@
<span class="latest-tag">(latest)</span>
</td>
<td>
- 2016-12-03
+ 2016-12-02
</td>
<td>
<a href="http://www.apache.org/dyn/closer.lua/apex/apache-apex-malhar-3.6.0/apache-apex-malhar-3.6.0-source-release.zip">malhar-3.6.0-source-release.zip</a><br>
@@ -259,7 +259,7 @@
<span class="latest-tag">(latest)</span>
</td>
<td>
- 2016-09-04
+ 2016-09-03
</td>
<td>
<a href="http://www.apache.org/dyn/closer.lua/apex/apache-apex-malhar-3.5.0/apache-apex-malhar-3.5.0-source-release.zip">malhar-3.5.0-source-release.zip</a><br>
http://git-wip-us.apache.org/repos/asf/apex-site/blob/76000d5f/content/release.html
----------------------------------------------------------------------
diff --git a/content/release.html b/content/release.html
index 865c3d9..9a03858 100644
--- a/content/release.html
+++ b/content/release.html
@@ -96,6 +96,7 @@
<p>If this is a minor release (X.Y.0), start with creating a new branch. Example for 3.4.0:</p>
<pre><code class="lang-bash">git checkout master && git pull
git checkout -b release-3.4 master
+git push apache release-3.4
</code></pre>
<p>Replace version in master branch:</p>
<pre><code>git checkout master
@@ -141,7 +142,7 @@ rv=3.4.0
git tag -a "v${rv}-RC1" -m "Release ${rv}-RC1"
</code></pre><p>Push to fork (as temporary branch), open pull request, wait for Travis CI build to succeed. Then push the tag.</p>
<pre><code>git push apache "v${rv}-RC1"
-</code></pre><p>The only difference between release branch and tag is this final version number change. The branch stays at <code>-SNAPSHOT</code> version.</p>
+</code></pre><p>The only difference between release branch and tag are this final version number change and the change log commit. The branch stays at <code>-SNAPSHOT</code> version.</p>
<h2 id="build-and-deploy-release-candidate">Build and Deploy Release Candidate</h2>
<p>Prerequisites:</p>
<ul>
@@ -219,23 +220,24 @@ git push
<a href="http://mail-archives.apache.org/mod_mbox/apex-dev/201605.mbox/%3CCAKJfLDPr3CBCfstQJWjchG-ZEYw5P%2Bwv5jN0tfy3EL%2BU%3DBUQgQ%40mail.gmail.com%3E">http://mail-archives.apache.org/mod_mbox/apex-dev/201605.mbox/%3CCAKJfLDPr3CBCfstQJWjchG-ZEYw5P%2Bwv5jN0tfy3EL%2BU%3DBUQgQ%40mail.gmail.com%3E</a></p>
<p>Vote result:
<a href="http://mail-archives.apache.org/mod_mbox/apex-dev/201605.mbox/%3CCAKJfLDNQzMN4zcuTHosU%2BCepF38A_2VL03GOYSc2%3DxxV-9iqMw%40mail.gmail.com%3E">http://mail-archives.apache.org/mod_mbox/apex-dev/201605.mbox/%3CCAKJfLDNQzMN4zcuTHosU%2BCepF38A_2VL03GOYSc2%3DxxV-9iqMw%40mail.gmail.com%3E</a></p>
+<p>Note that the vote result email should have the subject prefixed with <code>[RESULT]</code>.</p>
<p>If the vote is not successful, a new RC needs to be built and new vote called. Once the PMC vote passes, proceed with promoting and announcing the release.</p>
<h2 id="promote-release">Promote Release</h2>
<p>Release Nexus staging repository: <a href="http://central.sonatype.org/pages/releasing-the-deployment.html#close-and-drop-or-release-your-staging-repository">http://central.sonatype.org/pages/releasing-the-deployment.html#close-and-drop-or-release-your-staging-repository</a></p>
-<p>Move source release from dist staging to release folder:</p>
+<p>Move source release from dist staging to release folder (to be done by PMC member):</p>
<pre><code>rv=3.4.0
RNAME=apache-apex-core-${rv}
svn mv https://dist.apache.org/repos/dist/dev/apex/${RNAME}-RC1 https://dist.apache.org/repos/dist/release/apex/${RNAME} -m "Release ${RNAME}"
</code></pre><h3 id="jira">JIRA</h3>
-<p>Close release and all associated tickets (use bulk change workflow transition and turn off notification at bottom of page).
-Create version number X.Y.Z+1 for next release</p>
+<p>Close release and all associated tickets (use bulk change workflow transition and <strong>turn off notification</strong> at bottom of page to not flood the mailing list).
+Create version number X.Y.Z+1 for next release (to be done by PMC member).</p>
<h3 id="git">git</h3>
<p>Create final release tag:</p>
<pre><code class="lang-bash">rv=3.4.0
git tag -a "v${rv}" -m "Release ${rv}" "v${rv}-RC2"
git push apache "v${rv}"
</code></pre>
-<p>Bump patch version number in release branch (X.Y.Z+1 - otherwise same as when creating new release branch):</p>
+<p>Cherry-pick <code>@since</code> tag and change log commit from release tag and bump patch version number in release branch (X.Y.Z+1 - otherwise same as when creating new release branch):</p>
<pre><code class="lang-bash">git checkout release-3.4
dv=3.4.0-SNAPSHOT
rv=3.4.1-SNAPSHOT
http://git-wip-us.apache.org/repos/asf/apex-site/blob/76000d5f/content/roadmap.html
----------------------------------------------------------------------
diff --git a/content/roadmap.html b/content/roadmap.html
index d05362a..32d0edf 100644
--- a/content/roadmap.html
+++ b/content/roadmap.html
@@ -107,26 +107,6 @@
<tbody>
<tr>
<td>
- <a target="_blank" href="https://issues.apache.org/jira/browse/APEXCORE-163">APEXCORE-163</a>
- </td>
- <td title="Apex support modification of operator properties at runtime but the current implemenations has the following shortcomings.
-
-1. Property is not set across all partitions on the same window as individual partitions can be on different windows when property change is initiated from client resulting in inconsistency of data for those windows. I am being generous using the word inconsistent.
-2. Sometimes properties need to be set on more than one logical operators at the same time to achieve the change the user is seeking. Today they will be two separate changes happening on two different windows again resulting in inconsistent data for some windows. These would need to happen as a single transaction.
-3. If there is an operator failure before a committed checkpoint after an operator property is dynamically changed the operator will restart with the old property and the change will not be re-applied.
-
-Tim and myself did some brainstorming and we have a proposal to overcome these shortcomings. The main problem in all the above cases is that the property changes are happening out-of-band of data flow and hence independent of windowing. The proposal is to bring the property change request into the in-band dataflow so that they are handled consistently with windowing and handled distributively.
-
-The idea is to inject a special property change tuple containing the property changes and the identification information of the operator's they affect into the dataflow at the input operator. The tuple will be injected at window boundary after end window and before begin window and as this tuple flows through the DAG the intended operators properties will be modifed. They will all be modified consistently at the same window. The tuple can contain more than one property changes for more than one logical operators and the change will be applied consistently to the different logical operators at the same window. In case of failure the replay of tuples will ensure that the property change gets reapplied at the correct window.">
- Dynamic application property changes
- </td>
- <td>
-
-
- </td>
- </tr>
- <tr>
- <td>
<a target="_blank" href="https://issues.apache.org/jira/browse/APEXCORE-231">APEXCORE-231</a>
</td>
<td title="The Apex engine supports many platform level attributes like operator memory, application window count, container jvm options etc. Today these can only be set at application launch time and cannot be changed once the application is running.
@@ -161,18 +141,6 @@ b. A new operator needs to be added to the DAG to take data from an existing ope
</tr>
<tr>
<td>
- <a target="_blank" href="https://issues.apache.org/jira/browse/APEXCORE-233">APEXCORE-233</a>
- </td>
- <td title="There are scenarios where the same object instance needs to be specified for two attributes. Example is partitioner and stats listener, for partitioners that need to affect partitoning based on operator stats the same instance needs to be both. This is not possible to specify using a property file today as it will create two separate instances and can only be done in Java code today. The issue is to request adding this feature.">
- Ability to specify single instance objects in configuration
- </td>
- <td>
-
-
- </td>
- </tr>
- <tr>
- <td>
<a target="_blank" href="https://issues.apache.org/jira/browse/APEXCORE-234">APEXCORE-234</a>
</td>
<td title="The current property file specification follows the hadoop configuration file format and this has led to some drawbacks.
@@ -184,7 +152,7 @@ There will already be some changes afoot based on the following
b. There are also other ideas such as one from David to have the ability to specify global application level attributes which possible require rethinking the current syntax.
Users have also asked for an easier and more consistent way to specify these properties. This issue is to track the ideas and progress of these changes.">
- Investigate other ways to specify properties in property files
+ Better application configuration specification
</td>
<td>
@@ -320,29 +288,6 @@ This jira item can contain tasks for providing similar support in Apex">
</tr>
<tr>
<td>
- <a target="_blank" href="https://issues.apache.org/jira/browse/APEXMALHAR-2130">APEXMALHAR-2130</a>
- </td>
- <td title="This feature is used for supporting windowing.
-
-The storage needs to have the following features:
-1. Spillable key value storage (integrate with APEXMALHAR-2026)
-2. Upon checkpoint, it saves a snapshot for the entire data set with the checkpointing window id. This should be done incrementally (ManagedState) to avoid wasting space with unchanged data
-3. When recovering, it takes the recovery window id and restores to that snapshot
-4. When a window is committed, all windows with a lower ID should be purged from the store.
-5. It should implement the WindowedStorage and WindowedKeyedStorage interfaces, and because of 2 and 3, we may want to add methods to the WindowedStorage interface so that the implementation of WindowedOperator can notify the storage of checkpointing, recovering and committing of a window.
-">
- Scalable windowed storage
- </td>
- <td>
-
-
- <a target="_blank" href="https://issues.apache.org/jira/browse/APEXMALHAR/fixforversion/12338771">3.7.0</a>
-
-
- </td>
- </tr>
- <tr>
- <td>
<a target="_blank" href="https://issues.apache.org/jira/browse/APEXMALHAR-2260">APEXMALHAR-2260</a>
</td>
<td title="Support execution of Python code in an operator.
http://git-wip-us.apache.org/repos/asf/apex-site/blob/76000d5f/content/verification.html
----------------------------------------------------------------------
diff --git a/content/verification.html b/content/verification.html
index 9b795f0..5beed26 100644
--- a/content/verification.html
+++ b/content/verification.html
@@ -108,8 +108,8 @@ gpg --fingerprint <key-id>
<pre><code class="lang-bash">wget -r -np -nd <staging-area-link>/
</code></pre>
<p>Note the link should end with "/".</p>
-<p>Define the apex release candidate variable. We will set it up <em>apex-3.4.0</em> as an example.</p>
-<pre><code class="lang-bash">APEX_RELEASE_CANDIDATE=apex-3.4.0
+<p>Define the apex release candidate variable. We will use <em>apache-apex-core-3.6.0</em> as an example.</p>
+<pre><code class="lang-bash">APEX_RELEASE_CANDIDATE=apache-apex-core-3.6.0
</code></pre>
<p>Verify integrity of tar.gz file:</p>
<pre><code class="lang-bash">gpg --verify $APEX_RELEASE_CANDIDATE-source-release.tar.gz.asc