On this page
HowToRelease
此页面是为 Hive 提交者准备的。您需要提交者权限才能创建新的 Hive 版本.
Hadoop Version Warning
该页面假定您从 master 分支中释放,因此省略了使用 Maven 配置文件来确定要针对哪个版本的 Hadoop。如果要从 branch-1 释放,则需要在大多数 Maven 命令中添加-Phadoop-2
。
Storage API 发行
Hive 项目有两个单独发布的产品:
Storage-API –向量化和谓词下推类
Hive–Hive 的其余部分
大多数 Hive 版本将需要新的 storage-api 版本,并且当前的 storage-api 发布速度比 Hive 快,因此版本号也更高。
Storage API 准备主分支
如果这不是系列的第一个发行版(即 X.Y.0 发行版),请跳过此部分。
- 签出 master 分支
git checkout master
增加 storage-api/pom.xml 文件中
version
属性的值。例如,如果当前值为 2.5.0-SNAPSHOT
,则新值应为 2.6.0-SNAPSHOT
。请注意,SNAPSHOT
后缀是必需的,以表明这是一个未发布的开发分支。通过上述步骤,将根 pom.xml 和 standalone-metastore/pom.xml 中的 storage-api.version 属性更新为新值。
验证构建是否可以进行更改。
通过 Comments“准备为存储 api X.Y 1.0 进行开发”,将这些更改提交给 master。
Storage API 分支
如果这不是系列的第一个发行版(即 X.Y.0 发行版),请跳过此部分。
在#hive IRCChannels 和 dev @ hive 邮件列表上通知开发人员您将要发布版本。
为发行系列创建一个分支:
git checkout -b storage-branch-X.Y origin/master
更新 storage-api/pom.xml 文件中的
version
属性值。您应该删除SNAPSHOT
后缀,并将version
设置为X.Y.Z
,其中Z
是此发行系列中的点发行编号(第一个发行版为 0,在这种情况下,此步骤为空操作,因为您在创建分支时已在上面进行了此操作)。使用Maven 的版本插件来执行以下操作:验证构建是否可以进行更改。
提交这些更改并附带 Comments“准备为 storage-api X.Y.Z 发行”。
标记发布候选者(
R
是发布候选者编号,也从 0 开始):
git commit -a -m "Preparing for storage-api X.Y.Z release"
git push -u origin storage-branch-X.Y
git tag -a storage-release-X.Y.Z-rcR -m "Hive Storage API X.Y.Z-rcR release."
git push origin storage-release-X.Y.Z-rcR
使 Storage API 发布工件
确保您的发行说明已针对所有新提交进行了更新,并在必要时执行上述步骤。
创建并发布标签:
git tag storage-release-X.Y.Z-rcR -m "Hive Storage API X.Y.Z-rcR release."
git push origin storage-release-X.Y.Z-rcR
- 运行单元测试后,构建发行版(二进制和源版本)。手动创建 sha 文件。
% wget https://github.com/apache/hive/archive/storage-release-X.Y.Z-rcR.tar.gz
% tar xzvf storage-release-X.Y.Z-rcR.tar.gz
% mv storage-release-X.Y.Z-rcR/storage-api hive-storage-X.Y.Z
% tar czvf hive-storage-X.Y.Z-rcR.tar.gz hive-storage-X.Y.Z
% shasum -a 256 hive-storage-X.Y.Z-rcR.tar.gz > hive-storage-X.Y.Z-rcR.tar.gz.sha256
设置用于签名发行版的 PGP 密钥(如果还没有)。
参见https://www.apache.org/dev/release-signing.html,https://www.apache.org/dev/openpgp.html。
在发行版上签名(有关更多信息,请参见镜像发行的循序渐进指南)。
% gpg --armor --detach-sig hive-storage-X.Y.Z-rcR.tar.gz
- 检查签名。
% shasum -c hive-storage-X.Y.Z-rcR.tar.gz.sha256
hive-storage-X.Y.Z-rcR.tar.gz: OK
% gpg hive-storage-X.Y.Z-rcR.tar.gz.asc
gpg: assuming signed data in `hive-storage-X.Y.Z-rcR.tar.gz'
gpg: Signature made Fri Apr 28 12:50:03 2017 PDT using RSA key ID YOUR-KEY-ID
gpg: Good signature from "Your Name <YOUR-APACHE-ID@apache.org>"
- 将发布文件复制到公共场所。
% sftp YOUR-APACHE-ID@home.apache.org
sftp> cd public_html
sftp> mkdir hive-storage-X.Y.Z
sftp> cd hive-storage-X.Y.Z
sftp> put hive-storage-X.Y.Z-rcR.tar.gz*
sftp> quit
- 发送电子邮件给dev@hive.apache.org进行投票。
发布 Storage API 工件
- 发布投票通过后,将工件推送到 Nexus。 (如果您在尝试
export GPG_TTY=$(tty)
时遇到gpg: signing failed: Inappropriate ioctl for device
的错误,则表示该错误.)
% git checkout storage-release-X.Y.Z-rcR
% cd storage-api
% mvn -Papache-release -DskipTests clean deploy
登录 Nexus 并关闭存储库。将存储库标记为已发布。
创建最终标签(非常小心,“ rel /”中的标签不可更改)。
% git checkout storage-release-X.Y.Z-rcR
% git tag -s rel/storage-release-X.Y.Z -m "Hive Storage API X.Y.Z"
% git push origin rel/storage-release-X.Y.Z
- 将工件添加到 Hive 的 dist 区域。
% svn checkout https://dist.apache.org/repos/dist/release/hive hive-dist
% cd hive-dist
% mkdir hive-storage-X.Y.Z
% cd hive-storage-X.Y.Z
% wget https://home.apache.org/~YOUR-APACHE-ID/hive-storage-X.Y.Z/hive-storage-X.Y.Z-rcR.tar.gz{,.sha256,.asc}
% svn add .
% svn commit
为进一步 Developing 做准备
编辑 storage-api/pom.xml 以将版本更改为 X.Y.Z 1-SNAPSHOT。
编辑 pom.xml,将 storage-api.version 更改为 X.Y.Z 1-SNAPSHOT。
提交更改
% git commit -a -s -m 'Preparing for development post-X.Y.Z.'
% git push origin storage-branch-X.Y
清理 Storage API 工件
删除 storage-release-X.Y.Z-rcR 标签。
从 home.apache.org 中删除工件。
Hive Release
Preparation
批量更新 Jira,以从此发行版中取消分配所有已打开的非阻止程序问题,并将已完成的后续通知发送给开发人员列表。有两种 JIRA 需要注意:
目标版本或修订版本(旧版)设置为相关发行版的未解决的 JIRA。
- 已解决/已关闭(!)具有目标版本的 JIRA,但未将相关问题的修订版本设置为 JIRA(例如 JIRA 的目标是 2.0.0 和 1.3.0,但仅提交给 2.0.0)。
运行'mvn clean apache-rat:check'并检查生成的报告中是否有任何文件,尤其是应该都具有 Apache 许可证 Headers 的.java 文件。另请注意,运行此组件时,每个单独的组件都将在其中包含 rat.txt –例如,请确保检查 ql/target/rat.txt。将许可证 Headers 添加到任何缺少它的文件中(打开 jira 并提交补丁)。
在 NOTICE 中更新版权日期。如果其中提到的任何组件都有更新的版本,则需要更新这些组件的版权日期。 (ThejasComment:听起来只有在许可证需要这种归属的情况下,才需要在 NOTICE 中 Importing 条目.请参阅https://www.apache.org/legal/src-headers.html#notice。)
Branching
如果这不是系列的第一个发行版(即 X.Y.0 发行版),请跳过此部分。
在#hive IRCChannels 和 dev @ hive 邮件列表上通知开发人员您将要发布版本。
为发行系列创建一个分支:
git checkout -b branch-X.Y origin/master
git push -u origin branch-X.Y
- 在所有 pom.xml 文件中增加
version
属性的值。例如,如果当前值为0.7.0-SNAPSHOT
,则新值应为0.8.0-SNAPSHOT
。请注意,SNAPSHOT
后缀是必需的,以表明这是一个未发布的开发分支。这可以通过使用Maven 的版本插件的单个命令来完成,如下所示:
mvn versions:set -DnewVersion=X.Y.0-SNAPSHOT -DgenerateBackupPoms=false
更改 Metastore 升级脚本。有关如何针对 HIVE 0.13 进行的操作,请参见HIVE-6555。
验证构建是否可以进行更改。
通过 Comments“为 X.Y 1.0 开发做准备”将这些更改提交给 master。
更新发布分支
这些操作在发布分支中进行。
- 签出发布分支:
git clone https://git-wip-us.apache.org/repos/asf/hive.git/ <hive_src_dir>
cd <hive_src_dir>
git checkout branch-X.Y
- 更新所有 pom.xml 文件中的
version
属性值。您应该删除SNAPSHOT
后缀并将version
设置为hive-X.Y.Z
,其中 Z 是此发行系列中的点发行编号(第一个发行版为 0,在这种情况下,此步骤为空操作,因为您在创建分支时已在上面进行了此操作)。使用Maven 的版本插件来执行以下操作:
mvn versions:set -DnewVersion=0.7.0 -DgenerateBackupPoms=false
确保更新 standalone-metastore/pom.xml 和 upgrade-acid/pom.xml 中的 version 属性。
从要在顶层 pom.xml 中构建的模块列表中删除 storage-api。将 storage-api.version 属性设置为用于发行版的 storage-api 发行版。确保还要在 standalone-metastore/pom.xml 中设置 storage-api.version 属性。
更新
.reviewboardrc
文件中TRACKING_BRANCH
字段的值以指向origin/branch-X.Y
。验证构建是否可以进行更改。
通过 Comment“准备 X.Y.Z 版本”来提交这些更改。
如果尚未完成,请将所需的补丁从中继合并到分支中,然后提交这些更改。避免使用“ git merge”,以避免太多的合并提交。要么请求在 master 中提交该补丁的提交者提交该分支,要么自己提交,或者尝试对小补丁进行 git cherry-pick。此步骤的细节可以由发布 Management 器规定。
您可能还想提交一个补丁(在主干和分支上),以更新 README.txt 以使其更新(至少,搜索替换对版本号的引用)。还请检查“通知”,以查看是否需要更新任何内容以进行最近的库依赖项更改或添加。
选择当前版本中所有未修复的 JIRA,然后进行批量更新以清除“固定版本”字段。
同样,使用 JIRA 的Release Notes链接为 RELEASE_NOTES.txt 文件生成内容。确保选择“文本”格式。 (可以通过直接提交而不是补丁来执行此操作.)
用分支中的发行说明更新主干中的发行说明。
标记候选发布者(R 是候选发布者编号,也从 0 开始):
git tag -a release-X.Y.Z-rcR -m "Hive X.Y.Z-rcR release."
git push origin release-X.Y.Z-rcR
Building
确保您的发行说明已针对所有新提交进行了更新,并在必要时执行上述步骤。
运行单元测试后,构建发行版(二进制和源版本)。手动创建 sha256 文件。
% mvn install -Pdist -DskipTests -Dmaven.javadoc.skip=true -DcreateChecksum=true
% cd packaging/target
% shasum -a 256 apache-hive-X.Y.Z-bin.tar.gz > apache-hive-X.Y.Z-bin.tar.gz.sha256
% shasum -a 256 apache-hive-X.Y.Z-src.tar.gz > apache-hive-X.Y.Z-src.tar.gz.sha256
- 验证 SHA 256 校验和是否有效:
% shasum -a 256 -c apache-hive-X.Y.Z-bin.tar.gz.sha256
apache-hive-X.Y.Z-bin.tar.gz: OK
% shasum -a 256 -c apache-hive-X.Y.Z-src.tar.gz.sha256
apache-hive-X.Y.Z-src.tar.gz: OK
检查发行文件看起来是否正常-例如,安装它并运行教程中的示例。
设置用于签名发行版的 PGP 密钥(如果还没有)。
参见https://www.apache.org/dev/release-signing.html,https://www.apache.org/dev/openpgp.html。
在发行版上签名(有关更多信息,请参见镜像发行的循序渐进指南)。
% gpg --armor --output apache-hive-X.Y.Z-bin.tar.gz.asc --detach-sig apache-hive-X.Y.Z-bin.tar.gz
% gpg --armor --output apache-hive-X.Y.Z-src.tar.gz.asc --detach-sig apache-hive-X.Y.Z-src.tar.gz
- 将发布文件复制到公共场所。
% sftp YOUR-APACHE-ID@home.apache.org
sftp> cd public_html
sftp> mkdir apache-hive-X.Y.Z-rc-0
sftp> cd apache-hive-X.Y.Z-rc-0
sftp> put apache-hive-X.Y.Z*.tar.gz*
sftp> quit
- 将 Maven 工件发布到 Apache 临时存储库。确保针对 Apache 发行版具有此setup。 (如果尝试
export GPG_TTY=$(tty)
时遇到gpg: signing failed: Inappropriate ioctl for device
错误)。
% mvn deploy -DskipTests -Papache-release -Dmaven.javadoc.skip=true
- 登录到Apache Nexus 服务器并“关闭”已暂存的存储库。这使工件可以在临时 URL 上使用。
Voting
- 在 hive.apache.org 上对开发人员进行发布投票。
From: you@apache.org
To: dev@hive.apache.org
Subject: [VOTE] Apache Hive X.Y.Z Release Candidate N
Apache Hive X.Y.Z Release Candidate N is available here:
https://people.apache.org/~you/hive-X.Y.Z-candidate-N
Maven artifacts are available here:
https://repository.apache.org/content/repositories/orgapachehive-121/
The tag release-X.Y.Z-rcR has been applied to the source for this release in github, you can see it at
https://github.com/apache/hive/tree/release-X.Y.Z-rcR
Voting will conclude in 72 hours.
Hive PMC Members: Please test and vote.
Thanks.
验证发布候选
- 验证 PGP 签名:
#get the hive committers keys file
wget https://www.apache.org/dist/hive/KEYS
or
wget https://people.apache.org/keys/group/hive.asc
gpg --import <keys file>
gpg --verify hive-X.Y.Z-bin.tar.gz.asc hive-X.Y.Z-bin.tar.gz
gpg --verify hive-X.Y.Z.tar.gz.asc hive-X.Y.Z.tar.gz
- 验证 sha256 校验和:
请参阅“构建”下的步骤。
Publishing
三个 PMC 成员投票赞成发布一旦发布,就可以发布。
- 标记发布并删除发布候选标签:
git tag -s rel/release-X.Y.Z release-X.Y.Z-rcR -m "HiveX.Y.Z release." # where -rcR was the last tagged release candidate that passed the vote
git push origin rel/release-X.Y.Z
git tag -d release-X.Y.Z-rcR
git push origin :release-X.Y.Z-rcR
按照https://www.apache.org/dev/release-publishing.html#distribution中的说明将新发行的工件推送到https://www.apache.org/dist/,确保为新发行版创建一个新目录,然后将稳定链接重新链接到最新版本。请注意,您需要 PMC 权限才能执行此步骤-如果您没有此类权限,请 ping PMC member来为您执行此操作。
await24 小时以使释放传播到镜像。
在基本配置单元源目录中,如下生成 javadocs:
mvn clean install javadoc:javadoc javadoc:aggregate -DskipTests -Dadditionalparam=-Xdoclint:none
运行此命令后,您的\ <hive_source_dir>/target/site/apidocs 中应该存在 Javadocs
- 签出 javadocs svn 存储库,如下所示:
svn co https://svn.apache.org/repos/infra/websites/production/hive/content/javadocs
- 将生成的 javadocs 从源存储库复制到 javadocs 存储库,添加并提交:
mkdir <hive_javadocs_repo_dir>/rX.Y.Z/
cd <hive_javadocs_repo_dir>
cp -r <hive_source_dir>/target/site/apidocs ./rX.Y.Z/api
svn add rX.Y.Z
svn commit
如果这是一个错误修正版本,请 svn rm 过时的版本。 (例如,当为 r0.13.1 提交 javadocs 时,将删除 r0.13.0)
- 准备编辑网站。
svn co https://svn.apache.org/repos/asf/hive/cms/trunk
- 编辑文件 content/downloads.mdtext 和 javadoc.mdtext 以在适当的位置适当地添加新版本的条目。例如,对于 1.2.0,所做的 Importing 如下:
./content/downloads.mdtext:### 18 May 2015 : release 1.2.0 available
./content/downloads.mdtext:You can look at the complete [JIRA change log for this release][HIVE_1_2_0_CL].
./content/downloads.mdtext:[HIVE_1_2_0_CL]: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329345&styleName=Text&projectId=12310843
./content/javadoc.mdtext: * [Hive 1.2.0 Javadocs][r1.2.0]
./content/javadoc.mdtext:[r1.2.0]: /javadocs/r1.2.0/api/index.html
如您所见,您将需要此版本的发行说明链接,如本节先前创建的那样。
转到https://hive.staging.apache.org/hive/,获取配置单元工作副本,如果尚未看到更改,则强制使用新副本,然后要求其发布新副本。这应该根据您先前对 downloads.mdtext,javadoc.mdtext 所做的更改来更新 downloads 和 javadocs 页面,并且还可以使用新的 javadocs。如果您尚未看到它,则可能需要 await24 小时-届时应该在那里。
Update JIRA
确保仅处于“已修复”状态的问题的“修复版本”设置为发布 X.Y.Z。
发布版本。前往releases page。选择要发布的版本号,然后单击发布按钮。在此步骤中,您需要在 Hive 的 Jira 中具有“Management 员”角色。
解决发行版中已解决的问题。禁用此批量更改的邮件通知。
登录到Apache Nexus 服务器并将发布候选工件标记为已发布。
向 Hive
user
和dev
列表以及 Apacheannounce
列表发送发行公告。该电子邮件应从您的 Apache 电子邮件地址发送:
From: you@apache.org
To: user@hive.apache.org, dev@hive.apache.org, announce@apache.org
Subject: [ANNOUNCE] Apache Hive X.Y.Z Released
The Apache Hive team is proud to announce the release of Apache Hive
version X.Y.Z.
The Apache Hive (TM) data warehouse software facilitates querying and
managing large datasets residing in distributed storage. Built on top
of Apache Hadoop (TM), it provides, among others:
* Tools to enable easy data extract/transform/load (ETL)
* A mechanism to impose structure on a variety of data formats
* Access to files stored either directly in Apache HDFS (TM) or in other
data storage systems such as Apache HBase (TM)
* Query execution via Apache Hadoop MapReduce, Apache Tez and Apache Spark frameworks.
For Hive release details and downloads, please visit:
https://hive.apache.org/downloads.html
Hive X.Y.Z Release Notes are available here: [UPDATE THIS LINK]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310843&version=12316178
We would like to thank the many contributors who made this release
possible.
Regards,
The Apache Hive Team
为将来的维护版本准备分支
发布完成后,为下一个开发周期准备分支。
- 签出发布分支:
git clone https://git-wip-us.apache.org/repos/asf/hive.git/ <hive_src_dir>
cd <hive_src_dir>
git checkout branch-X.Y
- 在所有 pom.xml 文件中增加
version
属性值,并添加SNAPSHOT
后缀。例如,如果发布的版本为0.7.0
,则新值应为0.7.1-SNAPSHOT
。请注意,SNAPSHOT
后缀是必需的,以表明这是一个未发布的开发分支。使用Maven 的版本插件来执行以下操作:
mvn versions:set -DnewVersion=0.7.1-SNAPSHOT -DgenerateBackupPoms=false
如果您正在准备的发行版号移动了主要(第一个)或次要(第二个)编号,请更新 poms 中的 Hive 版本名称。在
pom.xml
和standalone-metastore/pom.xml
中搜索hive.version.shortname
属性。这应该与新版本号匹配。
例如,如果您正在开发 branch-3,并且刚刚发布了 Hive 3.2,并且正在为 Hive 3.3 开发准备分支,则需要将两个 pom 更新为<hive.version.shortname>3.3.0</hive.shortname.version>
。但是,如果您正在使用 branch-3.1 并刚刚发布了 Hive 3.1.2,并且正在准备进行 3.1.3 开发的分支,则没有必要。验证构建是否可以进行更改。
通过 Comment“为 X.Y.Z 1 开发做准备”来提交这些更改。