Apache ShardingSphere 参与&贡献指南合集

ShardingSphere是一个开放且活跃的社区,非常欢迎高质量的参与者与我们共建开源之路。

您可以从订阅官方邮件列表开始参与社区。

在成为一个贡献者之前,请您阅读贡献者指南官方文档指南以及开发规范

如果你想成为官方提交者,请您阅读提交者指南。官方提交者需要通过开启 2FA 后,才能够行使 Apache 官方代码仓库权限。

如果你想成为官方版本发布经理,请您阅读发布指南

感谢您关注ShardingSphere。


合集目录

订阅指南

在使用ShardingSphere的过程中,如果您发现任何问题,有新的想法、建议都可以通过Apache邮件列表参与到ShardingSphere的社区建设中。

  1. 发送订阅邮件。
    用自己的邮箱向dev-subscribe@shardingsphere.apache.org发送一封邮件,主题和内容任意。

  2. 接收确认邮件并回复。
    完成步骤1后,您将收到一封来自dev-help@shardingsphere.apache.org的确认邮件(如未收到,请确认该邮件是否已被拦截,或已经被自动归入订阅邮件、垃圾邮件、推广邮件等文件夹)。直接回复该邮件,或点击邮件里的链接快捷回复即可,主题和内容任意。

  3. 接收欢迎邮件。
    完成以上步骤后,您会收到一封主题为WELCOME to dev@shardingsphere.apache.org的欢迎邮件,至此您已成功订阅Apache ShardingSphere的邮件列表。

  4. 至此,您可以通过订阅的邮箱接收及回复邮件,或通过查看归档邮件来跟踪邮件对话。

搭建项目及环境指南

软件环境

软件 JDK Idea
版本 >=1.8 最新版本即可

安装步骤( Mac 为例)

1.JDK 安装

  • 下方链接获取适合自己环境的安装包( mac 选取 .dmg 格式)
  • Java Software | Oracle JDK.png
  • 下载完成后直接安装即可

2.设置环境变量

vim ~/.zprofile

  • 在下方添加环境变量:

#jdk环境通过 .dmg 方式安装后默认为下方路径 JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_301.jdk/Contents/Home PATH=$JAVA_HOME/bin:$PATH:. CLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/dt.jar:. export JAVA_HOME export PATH export CLASSPATH

source ~/.zprofile

3.Idea 下载安装

4.Idea clone 代码

5.项目编译

#假设项目路径为 /Users/hanmeimei/IdeaProjects/shardingsphere/ cd /Users/hanmeimei/IdeaProjects/shardingsphere/

编译环境

./mvnw -Dmaven.javadoc.skip=true -Djacoco.skip=true -DskipITs -DskipTests clean install

获取最新的项目

./mvnw -Dmaven.javadoc.skip=true -Djacoco.skip=true -DskipITs -DskipTests clean install -Prelease #进入下方目录位置 cd /Users/hanmeimei/shardingsphere/shardingsphere/shardingsphere-distribution/shardingsphere-proxy-distribution/target #即可看到打包好最新的软件 apache-shardingsphere-5.0.0-RC1-SNAPSHOT-shardingsphere-proxy-bin.tar.gz

结语

完成以上操作后,您已经有了 ShardingSphere 的软件环境,可以根据《贡献者指南》 参与到 ShardingSphere 的社区建设

贡献者指南

您可以报告bug,提交一个新的功能增强建议或者直接对以上内容提交改进补丁。

提交issue

  • 在提交issue之前,请经过充分的搜索,确定该issue不是通过简单的检索即可以解决的问题。
  • 查看issue列表,确定该issue不是一个重复的问题。
  • 新建一个issue并选择您的issue类型。
  • 使用一个清晰并有描述性的标题来定义issue。
  • 根据模板填写必要信息。
  • 在提交issue之后,对该issue分配合适的标签。如:bug,enhancement,discussion等。
  • 请对自己提交的issue保持关注,在讨论中进一步提供必要信息。

开发流程

1. Fork分支到本地,设置upstream

  • 从shardingsphere的repo上fork一个分支到您自己的repo来开始工作,并设置upstream为shardingsphere的repo。
git remote add upstream https://github.com/apache/shardingsphere.git

2. 选择issue

  • 请在选择您要修改的issue。如果是您新发现的问题或想提供issue中没有的功能增强,请先新建一个issue并设置正确的标签。
  • 在选中相关的issue之后,请回复以表明您当前正在这个issue上工作。并在回复的时候为自己设置一个deadline,添加至回复内容中。
  • 开发者列表中找到一个导师,导师会在设计与功能实现上给予即时的反馈。

3. 创建分支

  • 切换到fork的master分支,拉取最新代码,创建本次的分支。
git checkout master
git pull upstream master
git checkout -b issueNo

注意 :PR会按照squash的方式进行merge,如果不创建新分支,本地和远程的提交记录将不能保持同步。

4. 编码

  • 请您在开发过程中遵循ShardingSphere的开发规范。并在准备提交pull request之前完成相应的检查。
  • 将修改的代码push到fork库的分支上。
git add 修改代码
git commit -m 'commit log'
git push origin issueNo

5. 提交PR

  • 发送一个pull request到ShardingSphere的master分支。
  • 接着导师做CodeReview,然后他会与您讨论一些细节(包括设计,实现,性能等)。当导师对本次修改满意后,会将提交合并到当前开发版本的分支中。
  • 最后,恭喜您已经成为了ShardingSphere的官方贡献者!

6. 删除分支

  • 在导师将pull request合并到ShardingSphere的master分支中之后,您就可以将远程的分支(origin/issueNo)及与远程分支(origin/issueNo)关联的本地分支(issueNo)删除。
git checkout master
git branch -d issueNo
git push origin --delete issueNo

注意: 为了让您的id显示在contributor列表中,别忘了以下设置:

git config --global user.name "username"
git config --global user.email "username@mail.com"

提交者指南

提交者提名

ShardingSphere社区遵循Apache Community’s process 来接收新的提交者。
当您积极地参与ShardingSphere社区之后,项目管理委员会和项目官方提交者会根据您的表现发起吸纳您成为官方提交者和项目管理委员会成员的流程。

提交者责任

  • 开发新功能;
  • 代码重构;
  • 及时和可靠的评审Pull Request;
  • 思考和接纳新特性请求;
  • 解答问题;
  • 维护文档和代码示例;
  • 改进流程和工具;
  • 引导新的参与者融入社区。

日常工作

  1. 每周负责轮值的Committer需要每天查看社区待处理的Pull Request和Issue列表,负责问题的处理:
  • 包括标记issue,回复issue,关闭issue等;
  • 将issue分配至熟悉该模块的贡献者;
  • 轮值周期为一周。
  1. Assignee在被分配issue后,需要进行如下判断:
  • 判断是否是长期issue,如是,则标记为pending;
  • 判断issue类型,如:bug,enhancement,discussion等;
  • 标记Milestone。
  1. Committer提交的PR,需要根据PR类型和当前发布的周期标注Label和Milestone。

  2. Committer review PR时,可以进行squash and merge to master的操作, 如果有问题可以加上change request或者@相关人员协助处理。

轮值顺序表

序列 开始时间 姓名 GitHub ID
1 2021/8/16 潘娟 tristaZero
2 2021/8/23 欧阳文 avalon566
3 2021/8/30 蒋晓峰 SteNicholas
4 2021/9/6 江龙滔 RaigorJiang
5 2021/9/13 孟浩然 menghaoranss
6 2021/9/20 端正强 strongduanmu
7 2021/9/27 孙念君 taojintianxia
8 2021/10/4 孙念君 taojintianxia
9 2021/10/11 钟红胜 sandynz
10 2021/10/18 兰城翔 lanchengx
11 2021/10/25 吴伟杰 TeslaCN
12 2021/11/1 蒋平川 dachuan9e
13 2021/11/8 姜茂林 jiangML
14 2021/11/15 陆敬尚 jingshanglu
15 2021/11/22 赵锦超 zjcnb
16 2021/11/29 陈出新 tuichenchuxin
17 2021/12/6 王波 wbtlb
18 2021/12/13 武建东 wujiandong
19 2021/12/20 侯阳 soulasuna
20 2021/12/27 王小满 wgy8283335

开发规范

以下行为准则以完全遵循 Apache软件基金会行为准则为前提。

开发理念

  • 用心 保持责任心和敬畏心,以工匠精神持续雕琢。
  • 可读 代码无歧义,通过阅读而非调试手段浮现代码意图。
  • 整洁 认同《重构》和《代码整洁之道》的理念,追求整洁优雅代码。
  • 一致 代码风格、命名以及使用方式保持完全一致。
  • 精简 极简代码,以最少的代码表达最正确的意思。高度复用,无重复代码和配置。及时删除无用代码。
  • 抽象 层次划分清晰,概念提炼合理。保持方法、类、包以及模块处于同一抽象层级。
  • 极致 拒绝随意,保证任何一行代码、任何一个字母、任何一个空格都有其存在价值。

代码提交行为规范

  • 确保通过全部测试用例,确保执行 ./mvnw -T 1C clean install 可以编译和测试通过。
  • 确保覆盖率不低于 master 分支。
  • 确保使用 Checkstyle 检查代码,违反验证规则的需要有特殊理由。模板位置在https://github.com/apache/shardingsphere/blob/master/src/resources/checkstyle.xml,请使用checkstyle 8.8 运行规则。
  • 应尽量将设计精细化拆分;做到小幅度修改,多次数提交,但应保证提交的完整性。
  • 确保遵守编码规范。
  • 如果您使用 IDEA,可导入推荐的Settings

编码规范

  • 使用 linux 换行符。
  • 缩进(包含空行)和上一行保持一致。
  • 类声明后与下面的变量或方法之间需要空一行。
  • 不应有无意义的空行。请提炼私有方法,代替方法体过长或代码段逻辑闭环而采用的空行间隔。
  • 类、方法和变量的命名要做到顾名思义,避免使用缩写。
  • 返回值变量使用result命名;循环中使用each命名循环变量;map 中使用entry代替each
  • 捕获的异常名称命名为ex;捕获异常且不做任何事情,异常名称命名为ignored
  • 配置文件使用Spinal Case命名(一种使用-分割单词的特殊Snake Case)。
  • 需要注释解释的代码尽量提成小方法,用方法名称解释。
  • equals==条件表达式中,常量在左,变量在右;大于小于等条件表达式中,变量在左,常量在右。
  • 除了构造器入参与全局变量名称相同的赋值语句外,避免使用this修饰符。
  • 除了用于继承的抽象类之外,尽量将类设计为final
  • 嵌套循环尽量提成方法。
  • 成员变量定义顺序以及参数传递顺序在各个类和方法中保持一致。
  • 优先使用卫语句。
  • 类和方法的访问权限控制为最小。
  • 方法所用到的私有方法应紧跟该方法,如果有多个私有方法,书写私有方法应与私有方法在原方法的出现顺序相同。
  • 方法入参和返回值不允许为null
  • 优先使用三目运算符代替 if else 的返回和赋值语句。
  • 优先使用 lombok 代替构造器,getter, setter 方法和 log变量。
  • 优先考虑使用LinkedList,只有在需要通过下标获取集合中元素值时再使用ArrayList
  • ArrayListHashMap等可能产生扩容的集合类型必须指定集合初始大小,避免扩容。
  • 日志与注释一律使用英文。
  • 注释只能包含javadoc,todo 和 fixme。
  • 公开的类和方法必须有javadoc,其他类和方法以及覆盖自父类的方法无需javadoc。
  • 条件运算符(<表达式1> ? <表达式2> : <表达式3>)禁止嵌套使用

单元测试规范

  • 测试代码和生产代码需遵守相同代码规范。
  • 单元测试需遵循AIR(Automatic, Independent, Repeatable)设计理念。
    • 自动化(Automatic):单元测试应全自动执行,而非交互式。禁止人工检查输出结果,不允许使用System.outlog等,必须使用断言进行验证。
    • 独立性(Independent):禁止单元测试用例间的互相调用,禁止依赖执行的先后次序。每个单元测试均可独立运行。
    • 可重复执行(Repeatable):单元测试不能受到外界环境的影响,可以重复执行。
  • 单元测试需遵循 BCDE(Border, Correct, Design, Error)设计原则。
    • 边界值测试(Border):通过循环边界、特殊数值、数据顺序等边界的输入,得到预期结果。
    • 正确性测试(Correct):通过正确的输入,得到预期结果。
    • 合理性设计(Design):与生产代码设计相结合,设计高质量的单元测试。
    • 容错性测试(Error):通过非法数据、异常流程等错误的输入,得到预期结果。
  • 如无特殊理由,测试需全覆盖。
  • 每个测试用例需精确断言。
  • 准备环境的代码和测试代码分离。
  • 只有junit Assert,hamcrest CoreMatchers,Mockito相关可以使用static import。
  • 单数据断言,应使用assertTrueassertFalseassertNullassertNotNull
  • 多数据断言,应使用assertThat
  • 精确断言,尽量不使用notcontainsString断言。
  • 测试用例的真实值应名为为 actualXXX,期望值应命名为 expectedXXX。
  • 测试类和@Test标注的方法无需 javadoc。

G4 编码规范

  • 公共规范
    • 每行长度不超过200个字符,保证每一行语义完整以便于理解。
  • 词法解析规范
    • 每个规则一行,规则间无需空行。
    • 规则名称使用大写字母。如果名称由多个单词组成,用下划线间隔。DataTypeSymbol的规则命名以下划线结尾。与ANTLR内置变量或关键字重名的规则在结尾加下划线以示区分。
    • 不对外暴露的规则使用fragmentfragment定义的规则需在其服务的规则之后声明。
    • 公用规则定义放在Keyword.g4,每个数据库可以有自己特有的规则定义。例如:MySQLKeyword.g4
  • 语法解析规范
    • 每个规则结束后空一行,空行无需缩进。
    • 规则名称前面不空格,冒号后空一格再开始写规则,分号在单独一行并保持和上一行相同缩进。
    • 如果一个规则的分支超过5个,则每个分支一行。
    • 规则命名采用 java 变量的驼峰形式。
    • 为每种 SQL 语句类型定义一个独立的语法文件,文件名称由数据库名称 + 语句类型名称 + Statement。例如:MySQLDQLStatement.g4

Issue 提交与处理规范

Issue 提交规范

  • Issue 列表以可读和可检索为目标。提交者有义务将标题总结的有意义和易于检索,并保持内容的正确和完整性;
  • 请在经过充分的检索之后,确定无相关的已存在 Issue,再提交新的 Issue;
  • Issue 类型划分为缺陷报告、新功能请求和问题,请在提交 Issue 时选择正确的模板并根据模板填写其内容;
  • 由配置不确定等产生的问题,请将相关的可重现代码提交至 Github,以便于社区贡献者定位和确定问题;
  • 请在 Issue 得到解决之后,回复该 Issue,形成闭环,为其他浏览此 Issue 的读者提供有效信息;
  • 请及时关注已提交的 Issue,长时间无反馈的 Issue 将定期关闭;
  • 为保证社区多元化,请使用英文参与交流。

Issue 处理规范

  • 对于标题不明晰的 Issue,由处理人引导提交者将标题修改完善后再行处理;
  • 对于内容缺失模板必要信息的 Issue,由处理人引导提交者将所需信息提供完善后再行处理;
  • 涉及到缺陷修复、功能提升等与代码相关的 Issue,都将标记正确的标签以及完成此 Issue 的项目版本;
  • 处理人将定期关闭长时间无反馈的 Issue;
  • 无参考和检索价值的 Issue 将被标记为 status:invalid,读者无需关注。

官方文档贡献指南

如果您想帮助贡献 ShardingSphere 文档或网站,我们很乐意为您提供帮助!任何人都可以贡献,无论您是刚接触项目还是已经使用 ShardingSphere 很长时间,无论是自我认同的开发人员、最终用户,还是那些无法忍受错别字的人,都可以对文档或者网站进行贡献。

在贡献者指南里,已经提到如何提交 Issues 与 Pull Request,这里我们将要介绍如何给官方文档提交 Pull Request。

前置条件

Fork 文档项目

Fork ShardingSphere 的 master 分支。

目录结构说明

shardingsphere
├─docs
  ├─community
  │  ├─archetypes
  │  ├─content
  │  │  ├─contribute
  │  │  ├─powered-by
  │  │  ├─security
  │  │  └─team
  │  ├─layouts
  │  ├─static
  │  └─themes
  ├─document
  │  ├─archetypes
  │  ├─content
  │  │  ├─concepts
  │  │  │  ├─adaptor
  │  │  │  ├─distsql
  │  │  │  ├─mode
  │  │  │  └─pluggable         
  │  │  ├─dev-manual
  │  │  ├─downloads
  │  │  ├─features
  │  │  │  ├─encrypt
  │  │  │  ├─governance
  │  │  │  ├─readwrite-splitting
  │  │  │  ├─scaling
  │  │  │  ├─shadow
  │  │  │  ├─sharding
  │  │  │  │  ├─concept
  │  │  │  │  ├─principle
  │  │  │  │  └─use-norms
  │  │  │  ├─test-engine
  │  │  │  └─transaction
  │  │  │      ├─concept
  │  │  │      ├─principle
  │  │  │      └─use-norms
  │  │  ├─others
  │  │  │  ├─api-change-history
  │  │  │  └─faq    
  │  │  ├─overview
  │  │  ├─quick-start
  │  │  ├─user-manual
  │  │  │  ├─shardingsphere-jdbc
  │  │  │  │  ├─configuration
  │  │  │  │  └─usage
  │  │  │  ├─shardingsphere-proxy
  │  │  │  ├─shardingsphere-sidecar
  │  │  │  └─shardingsphere-scaling  
  │  ├─i18n
  │  ├─layouts
  │  ├─static
  │  └─themes

文档基础知识

ShardingSphere 文档使用 Markdown 编写,并使用 Hugo 进行处理生成 html,部署于 asf-site 分支,源代码位于 Github

您可以从 Github 网站上提交问题,编辑内容和查看其他人的更改。

页面模板

页面模板位于 themes 中的 layouts/partials/ 目录中。

提出具体可查找的问题

任何拥有 Github 帐户的人都可以针对 ShardingSphere 文档提出问题(错误报告)。如果您发现错误,即使您不知道如何修复它,也应提出问题。

如何提出问题?

  1. 附加出现问题的文档链接。

  2. 详细描述问题。

  3. 描述问题对用户造成的困扰。

  4. 提出建议修复的方式。

  5. IssuesNew issue 提出您的问题。

提交更改

操作步骤如下:

  1. 首先,你需要在 master 分支目录结构中定位出你要操作的文件。
  2. 文件操作完成后,提 pull request 到 master 分支。

约定

  • 非特别说明,请使用 Hugo 的0.70.0版本

  • asf-site 分支由官方定期更新,您无需向 asf-site 提交 pull request

ShardingSphere 发布指南

准备工作

1. 确认 Release Note

Release Note 需提供中文/英文两种版本,确认中文描述是否明确,英文翻译是否准确,并按以下标签进行分类:

  1. 新功能
  2. API 变更
  3. 功能增强
  4. 重构
  5. 漏洞修复

2. 确认 Issue 列表

打开 Github Issues ,过滤 Milestone 为 ${RELEASE.VERSION} 且状态为打开的 Issue:

  1. 关闭已完成的 Issue
  2. 未完成的 Issue 与负责人进行沟通,如果不影响本次发版,修改 Milestone 为下一个版本
  3. 确认发布版本的 Milestone 下没有打开状态的 Issue

3. 确认 Pull request 列表

打开 Github Pull requests ,过滤 Milestone 为 ${RELEASE.VERSION} 且状态为打开的 Pull request:

  1. 对打开的 Pull request 进行 Review 并且 Merge
  2. 无法 Merge 且不影响本次发版的 Pull request,修改 Milestone 为下一个版本
  3. 确认发布版本的 Milestone 下没有打开状态的 Pull request

4. 关闭 Milestone

打开 Github Milestone

  1. 确认 ${RELEASE.VERSION} 的 Milestone 完成状态为 100%
  2. 点击 Close 关闭 Milestone

5. 发送讨论邮件

  1. 发送邮件至 dev@shardingsphere.apache.org,在邮件正文中描述或链接 Release Note
  2. 关注邮件列表,确认社区开发者对 Release Note 没有任何疑问

GPG 设置

1. 安装 GPG

GnuPG官网下载安装包。
GnuPG 的 1.x 版本和 2.x 版本的命令有细微差别,下列说明以GnuPG-2.1.23版本为例。

安装完成后,执行以下命令查看版本号。

gpg --version

2. 创建 key

安装完成后,执行以下命令创建 key。

GnuPG-2.x可使用:

gpg --full-gen-key

GnuPG-1.x可使用:

gpg --gen-key

根据提示完成 key:

注意:请使用 Apache mail 生成 GPG 的 Key。

gpg (GnuPG) 2.0.12; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
  (1) RSA and RSA (default)
  (2) DSA and Elgamal
  (3) DSA (sign only)
  (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
        0 = key does not expire
     <n>  = key expires in n days
     <n>w = key expires in n weeks
     <n>m = key expires in n months
     <n>y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: ${输入用户名}
Email address: ${输入邮件地址}
Comment: ${输入注释}
You selected this USER-ID:
   "${输入的用户名} (${输入的注释}) <${输入的邮件地址}>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key. # 输入密码

3. 查看生成的 key

gpg --list-keys

执行结果:

pub   4096R/700E6065 2019-03-20
uid                  ${用户名} (${注释}) <{邮件地址}>
sub   4096R/0B7EF5B2 2019-03-20

其中 700E6065 为公钥 ID。

4. 将公钥同步到服务器

命令如下:

gpg --keyserver hkp://pool.sks-keyservers.net --send-key 700E6065

pool.sks-keyservers.net为随意挑选的公钥服务器,每个服务器之间是自动同步的,选任意一个即可。

发布 Apache Maven 中央仓库

**1. 设置 settings.xml文件 **

将以下模板添加到 ~/.m2/settings.xml中,所有密码需要加密后再填入。
加密设置可参考这里

<settings>
  <servers>
    <server>
      <id>apache.snapshots.https</id>
      <username> <!-- APACHE LDAP 用户名 --> </username>
      <password> <!-- APACHE LDAP 加密后的密码 --> </password>
    </server>
    <server>
      <id>apache.releases.https</id>
      <username> <!-- APACHE LDAP 用户名 --> </username>
      <password> <!-- APACHE LDAP 加密后的密码 --> </password>
    </server>
  </servers>
</settings>

2. 创建发布分支

假设从 github 下载的 ShardingSphere 源代码在~/shardingsphere/目录;假设即将发布的版本为${RELEASE.VERSION}
创建${RELEASE.VERSION}-release分支,接下来的操作都在该分支进行。

## ${name}为源码所在分支,如:master,dev-4.x
git clone --branch ${name} https://github.com/apache/shardingsphere.git ~/shardingsphere
cd ~/shardingsphere/
git pull
git checkout -b ${RELEASE.VERSION}-release
git push origin ${RELEASE.VERSION}-release

3. 更新版本说明和示例版本

在发布分支上更新如下文件,并提交 PR 到发布分支:

https://github.com/apache/shardingsphere/blob/${RELEASE.VERSION}-release/RELEASE-NOTES.md

更新examples模块的 pom,将版本由${CURRENT.VERSION} 替换为${RELEASE.VERSION},并提交 PR 到发布分支。

4. 发布预校验

mvn release:prepare -Prelease -Darguments="-DskipTests" -DautoVersionSubmodules=true -DdryRun=true -Dusername=${Github用户名}

-Prelease: 选择 release 的 profile,这个 profile 会打包所有源码、jar 文件以及 ShardingSphere-Proxy 的可执行二进制包。

-DautoVersionSubmodules=true:作用是发布过程中版本号只需要输入一次,不必为每个子模块都输入一次。

-DdryRun=true:演练,即不产生版本号提交,不生成新的 tag。

5. 准备发布

首先清理发布预校验本地信息。

mvn release:clean
mvn release:prepare -Prelease -Darguments="-DskipTests" -DautoVersionSubmodules=true -DpushChanges=false -Dusername=${Github 用户名}

和上一步演练的命令基本相同,去掉了-DdryRun=true 参数。

-DpushChanges=false:不要将修改后的版本号和 tag 自动提交至 Github。

将本地文件检查无误后,提交至 github。

git push origin ${RELEASE.VERSION}-release
git push origin --tags

6. 部署发布

mvn release:perform -Prelease -Darguments="-DskipTests" -DautoVersionSubmodules=true -Dusername=${Github 用户名}

执行完该命令后,待发布版本会自动上传到 Apache 的临时筹备仓库(staging repository)。
访问https://repository.apache.org/#stagingRepositories, 使用 Apache 的 LDAP 账户登录后,就会看到上传的版本,Repository列的内容即为 ${STAGING.REPOSITORY}。
点击Close来告诉 Nexus 这个构建已经完成,只有这样该版本才是可用的。
如果电子签名等出现问题,Close会失败,可以通过Activity查看失败信息。

发布 Apache SVN 仓库

1. 检出 shardingsphere 发布目录

如无本地工作目录,则先创建本地工作目录。

mkdir -p ~/ss_svn/dev/
cd ~/ss_svn/dev/

创建完毕后,从 Apache SVN 检出 shardingsphere 发布目录。

svn --username=${APACHE LDAP 用户名} co https://dist.apache.org/repos/dist/dev/shardingsphere
cd ~/ss_svn/dev/shardingsphere

2. 添加 gpg 公钥

仅第一次部署的账号需要添加,只要KEYS中包含已经部署过的账户的公钥即可。

gpg -a --export ${GPG用户名} >> KEYS

3. 将待发布的内容添加至 SVN 目录

创建版本号目录。

mkdir -p ~/ss_svn/dev/shardingsphere/${RELEASE.VERSION}
cd ~/ss_svn/dev/shardingsphere/${RELEASE.VERSION}

将源码包、二进制包和 ShardingSphere-Proxy 可执行二进制包添加至 SVN 工作目录。

cp -f ~/shardingsphere/shardingsphere-distribution/shardingsphere-src-distribution/target/*.zip* ~/ss_svn/dev/shardingsphere/${RELEASE.VERSION}
cp -f ~/shardingsphere/shardingsphere-distribution/shardingsphere-jdbc-distribution/target/*.tar.gz* ~/ss_svn/dev/shardingsphere/${RELEASE.VERSION}
cp -f ~/shardingsphere/shardingsphere-distribution/shardingsphere-proxy-distribution/target/*.tar.gz* ~/ss_svn/dev/shardingsphere/${RELEASE.VERSION}

4. 提交 Apache SVN

svn add *
svn --username=${APACHE LDAP 用户名} commit -m "release ${RELEASE.VERSION}"

检查发布结果

检查 sha512 哈希

shasum -c apache-shardingsphere-${RELEASE.VERSION}-*.sha512

检查 gpg 签名

首先导入发布人公钥。从 svn 仓库导入 KEYS 到本地环境。(发布版本的人不需要再导入,帮助做验证的人需要导入,用户名填发版人的即可)

curl https://dist.apache.org/repos/dist/dev/shardingsphere/KEYS >> KEYS
gpg --import KEYS
gpg --edit-key "${发布人的 gpg 用户名}"
  > trust

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5

  > save

然后进行 gpg 签名检查。

gpg --verify apache-shardingsphere-${RELEASE.VERSION}-src.zip.asc apache-shardingsphere-${RELEASE.VERSION}-src.zip
gpg --verify apache-shardingsphere-${RELEASE.VERSION}-shardingsphere-jdbc-bin.tar.gz.asc apache-shardingsphere-${RELEASE.VERSION}-shardingsphere-jdbc-bin.tar.gz
gpg --verify apache-shardingsphere-${RELEASE.VERSION}-shardingsphere-proxy-bin.tar.gz.asc apache-shardingsphere-${RELEASE.VERSION}-shardingsphere-proxy-bin.tar.gz

检查发布文件内容

对比源码包与 Github 上 tag 的内容差异

curl -Lo tag-${RELEASE.VERSION}.zip https://github.com/apache/shardingsphere/archive/${RELEASE.VERSION}.zip
unzip tag-${RELEASE.VERSION}.zip
unzip apache-shardingsphere-${RELEASE.VERSION}-src.zip
diff -r apache-shardingsphere-${RELEASE.VERSION}-src-release shardingsphere-${RELEASE.VERSION}

检查源码包的文件内容

  • 检查源码包是否包含由于包含不必要文件,致使 tarball 过于庞大
  • 存在LICENSENOTICE文件
  • NOTICE文件中的年份正确
  • 只存在文本文件,不存在二进制文件
  • 所有文件的开头都有 ASF 许可证
  • 能够正确编译,单元测试可以通过 (./mvnw -T 1C install)
  • 检查是否有多余文件或文件夹,例如空文件夹等

检查二进制包的文件内容

解压缩
apache-shardingsphere-${RELEASE.VERSION}-shardingsphere-jdbc-bin.tar.gz
apache-shardingsphere-${RELEASE.VERSION}-shardingsphere-proxy-bin.tar.gz
进行如下检查:

  • 存在LICENSENOTICE文件
  • NOTICE文件中的年份正确
  • 所有文本文件开头都有 ASF 许可证
  • 检查第三方依赖许可证:
    • 第三方依赖的许可证兼容
    • 所有第三方依赖的许可证都在LICENSE文件中声名
    • 依赖许可证的完整版全部在license目录
    • 如果依赖的是Apache许可证并且存在NOTICE文件,那么这些NOTICE文件也需要加入到版本的NOTICE文件中

发起投票

投票阶段

  1. ShardingSphere 社区投票,发起投票邮件到dev@shardingsphere.apache.org。PMC 需要先按照文档检查版本的正确性,然后再进行投票。
    经过至少 72 小时并统计到 3 个+1 PMC member票后,即可进入下一阶段的投票。

  2. 宣布投票结果,发起投票结果邮件到dev@shardingsphere.apache.org

投票模板

  1. ShardingSphere 社区投票模板

标题:

[VOTE] Release Apache ShardingSphere ${RELEASE.VERSION}

正文:

Hello ShardingSphere Community,

This is a call for vote to release Apache ShardingSphere version ${RELEASE.VERSION}

Release notes:
https://github.com/apache/shardingsphere/blob/master/RELEASE-NOTES.md

The release candidates:
https://dist.apache.org/repos/dist/dev/shardingsphere/${RELEASE.VERSION}/

Maven 2 staging repository:
https://repository.apache.org/content/repositories/${STAGING.REPOSITORY}/org/apache/shardingsphere/

Git tag for the release:
https://github.com/apache/shardingsphere/tree/${RELEASE.VERSION}/

Release Commit ID:
https://github.com/apache/shardingsphere/commit/xxxxxxxxxxxxxxxxxxxxxxx

Keys to verify the Release Candidate:
https://dist.apache.org/repos/dist/dev/shardingsphere/KEYS

Look at here for how to verify this release candidate:
https://shardingsphere.apache.org/community/en/contribute/release/

GPG user ID:
${YOUR.GPG.USER.ID}

The vote will be open for at least 72 hours or until necessary number of votes are reached.

Please vote accordingly:

[ ] +1 approve 

[ ] +0 no opinion
 
[ ] -1 disapprove with the reason

PMC vote is +1 binding, all others is +1 non-binding.

Checklist for reference:

[ ] Download links are valid.

[ ] Checksums and PGP signatures are valid.

[ ] Source code distributions have correct names matching the current release.

[ ] LICENSE and NOTICE files are correct for each ShardingSphere repo.

[ ] All files have license headers if necessary.

[ ] No compiled archives bundled in source archive.
  1. 宣布投票结果模板:

标题:

[RESULT][VOTE] Release Apache ShardingSphere ${RELEASE.VERSION}

正文:

We’ve received 3 +1 binding votes and one +1 non-binding vote:

+1 binding, xxx
+1 binding, xxx
+1 binding, xxx

+1 non-binding, xxx

Thank you everyone for taking the time to review the release and help us. 
I will process to publish the release and send ANNOUNCE.

完成发布

1. 将源码、二进制包以及 KEYS 从 svn 的 dev 目录移动到 release 目录

svn mv https://dist.apache.org/repos/dist/dev/shardingsphere/${RELEASE.VERSION} https://dist.apache.org/repos/dist/release/shardingsphere/ -m "transfer packages for ${RELEASE.VERSION}"
svn delete https://dist.apache.org/repos/dist/release/shardingsphere/KEYS -m "delete KEYS"
svn cp https://dist.apache.org/repos/dist/dev/shardingsphere/KEYS https://dist.apache.org/repos/dist/release/shardingsphere/ -m "transfer KEYS for ${RELEASE.VERSION}"

2. 在 Apache Staging 仓库找到 ShardingSphere 并点击Release

3. 合并 Github 的 release 分支到master, 合并完成后删除 release 分支

git checkout master
git merge origin/${RELEASE.VERSION}-release
git pull
git push origin master
git push --delete origin ${RELEASE.VERSION}-release
git branch -d ${RELEASE.VERSION}-release

4. 修改 README 文件

README.mdREADME_ZH.md里的${PREVIOUS.RELEASE.VERSION}修改为${RELEASE.VERSION}

5. 发布 Docker

5.1 准备工作

本地安装 Docker,并启动服务。

5.2 编译 Docker 镜像

git checkout ${RELEASE.VERSION}
cd ~/shardingsphere/shardingsphere-distribution/shardingsphere-proxy-distribution/
mvn clean package -Prelease,docker

5.3 给本地 Docker 镜像打标记

通过docker images查看到 IMAGE ID,例如为:e9ea51023687

docker tag e9ea51023687 apache/shardingsphere-proxy:latest
docker tag e9ea51023687 apache/shardingsphere-proxy:${RELEASE.VERSION}

5.4 发布 Docker 镜像

docker login
docker push apache/shardingsphere-proxy:latest
docker push apache/shardingsphere-proxy:${RELEASE_VERSION}

5.5 确认发布成功

登录 Docker Hub 查看是否有发布的镜像

6. GitHub版本发布

GitHub Releases 页面的 ${RELEASE_VERSION} 版本上点击 Edit

编辑版本号及版本说明,并点击 Publish release

7. 更新下载页面

等待并确认新的发布版本同步至 Apache 镜像后,更新如下页面:

https://shardingsphere.apache.org/document/current/en/downloads/

https://shardingsphere.apache.org/document/current/cn/downloads/

GPG签名文件和哈希校验文件的下载连接应该使用这个前缀:https://downloads.apache.org/shardingsphere/

最新版本中保留一个最新的版本。Incubator阶段历史版本会自动归档到Archive repository

8. 邮件通知版本发布完成

发送邮件到dev@shardingsphere.apache.organnounce@apache.org通知完成版本发布

通知邮件模板(使用纯文本模式):

标题:

[ANNOUNCE] Apache ShardingSphere ${RELEASE.VERSION} available

正文:

Hi all,

Apache ShardingSphere Team is glad to announce the new release of Apache ShardingSphere ${RELEASE.VERSION}.

Apache ShardingSphere is an open-source ecosystem consisted of a set of distributed database solutions, including 3 independent products, JDBC, Proxy & Sidecar (Planning). 
They all provide functions of data scale out, distributed transaction and distributed governance, applicable in a variety of situations such as Java isomorphism, heterogeneous language and cloud native.
Apache ShardingSphere aiming at reasonably making full use of the computation and storage capacity of existed database in distributed system, rather than a totally new database. 
As the cornerstone of enterprises, relational database still takes a huge market share. Therefore, we prefer to focus on its increment instead of a total overturn.

Download Links: https://shardingsphere.apache.org/document/current/en/downloads/

Release Notes: https://github.com/apache/shardingsphere/blob/master/RELEASE-NOTES.md

Website: https://shardingsphere.apache.org/

ShardingSphere Resources:
- Issue: https://github.com/apache/shardingsphere/issues/
- Mailing list: dev@shardingsphere.apache.org
- Documents: https://shardingsphere.apache.org/document/current/



- Apache ShardingSphere Team

ElasticJob 发布指南

GPG设置

详情请参见发布指南

发布Apache Maven中央仓库

1. 设置settings.xml文件

将以下模板添加到 ~/.m2/settings.xml中,所有密码需要加密后再填入。
加密设置可参考这里

<settings>
  <servers>
    <server>
      <id>apache.snapshots.https</id>
      <username> <!-- APACHE LDAP 用户名 --> </username>
      <password> <!-- APACHE LDAP 加密后的密码 --> </password>
    </server>
    <server>
      <id>apache.releases.https</id>
      <username> <!-- APACHE LDAP 用户名 --> </username>
      <password> <!-- APACHE LDAP 加密后的密码 --> </password>
    </server>
  </servers>
</settings>

2. 更新版本说明和示例版本

在Github主干上更新如下文件,并提交PR到主干:

https://github.com/apache/shardingsphere-elasticjob/blob/master/RELEASE-NOTES.md

更新examples模块的pom,将版本由${CURRENT.VERSION}替换为${RELEASE.VERSION}。

3. 创建发布分支

假设从github下载的ElasticJob源代码在~/elasticjob/目录;假设即将发布的版本为${RELEASE.VERSION}
创建${RELEASE.VERSION}-release分支,接下来的操作都在该分支进行。

## ${name}为源码所在分支,如:master,dev-4.x
git clone --branch ${name} https://github.com/apache/shardingsphere-elasticjob.git ~/elasticjob
cd ~/elasticjob/
git pull
git checkout -b ${RELEASE.VERSION}-release
git push origin ${RELEASE.VERSION}-release

4. 发布预校验

mvn release:prepare -Prelease -Darguments="-DskipTests" -DautoVersionSubmodules=true -DdryRun=true -Dusername=${Github用户名}

-Prelease: 选择release的profile,这个profile会打包所有源码和jar文件。

-DautoVersionSubmodules=true:作用是发布过程中版本号只需要输入一次,不必为每个子模块都输入一次。

-DdryRun=true:演练,即不产生版本号提交,不生成新的tag。

5. 准备发布

首先清理发布预校验本地信息。

mvn release:clean
mvn release:prepare -Prelease -Darguments="-DskipTests" -DautoVersionSubmodules=true -DpushChanges=false -Dusername=${Github用户名}

和上一步演练的命令基本相同,去掉了-DdryRun=true参数。

-DpushChanges=false:不要将修改后的版本号和tag自动提交至Github。

将本地文件检查无误后,提交至github。

git push origin ${RELEASE.VERSION}-release
git push origin --tags

6. 部署发布

mvn release:perform -Prelease -Darguments="-DskipTests" -DautoVersionSubmodules=true -Dusername=${Github用户名}

执行完该命令后,待发布版本会自动上传到Apache的临时筹备仓库(staging repository)。
访问https://repository.apache.org/#stagingRepositories, 使用Apache的LDAP账户登录后,就会看到上传的版本,Repository列的内容即为${STAGING.REPOSITORY}。
点击Close来告诉Nexus这个构建已经完成,只有这样该版本才是可用的。
如果电子签名等出现问题,Close会失败,可以通过Activity查看失败信息。

发布Apache SVN仓库

1. 检出shardingsphere发布目录

如无本地工作目录,则先创建本地工作目录。

mkdir -p ~/ss_svn/dev/
cd ~/ss_svn/dev/

创建完毕后,从Apache SVN检出shardingsphere发布目录。

svn --username=${APACHE LDAP 用户名} co https://dist.apache.org/repos/dist/dev/shardingsphere
cd ~/ss_svn/dev/shardingsphere

2. 添加gpg公钥

仅第一次部署的账号需要添加,只要KEYS中包含已经部署过的账户的公钥即可。

gpg -a --export ${GPG用户名} >> KEYS

3. 将待发布的内容添加至SVN目录

创建版本号目录。

mkdir -p ~/ss_svn/dev/shardingsphere/elasticjob-${RELEASE.VERSION}
cd ~/ss_svn/dev/shardingsphere/elasticjob-${RELEASE.VERSION}

将源码包和二进制包添加至SVN工作目录。

cp -f ~/elasticjob/elasticjob-distribution/elasticjob-src-distribution/target/*.zip* ~/ss_svn/dev/shardingsphere/elasticjob-${RELEASE.VERSION}
cp -f ~/elasticjob/elasticjob-distribution/elasticjob-lite-distribution/target/*.tar.gz* ~/ss_svn/dev/shardingsphere/elasticjob-${RELEASE.VERSION}
cp -f ~/elasticjob/elasticjob-distribution/elasticjob-cloud-executor-distribution/target/*.tar.gz* ~/ss_svn/dev/shardingsphere/elasticjob-${RELEASE.VERSION}
cp -f ~/elasticjob/elasticjob-distribution/elasticjob-cloud-scheduler-distribution/target/*.tar.gz* ~/ss_svn/dev/shardingsphere/elasticjob-${RELEASE.VERSION}

4. 提交Apache SVN

svn add *
svn --username=${APACHE LDAP 用户名} commit -m "release elasticjob-${RELEASE.VERSION}"

检查发布结果

检查sha512哈希

shasum -c apache-shardingsphere-elasticjob-${RELEASE.VERSION}-*.sha512

检查gpg签名

首先导入发布人公钥。从svn仓库导入KEYS到本地环境。(发布版本的人不需要再导入,帮助做验证的人需要导入,用户名填发版人的即可)

curl https://dist.apache.org/repos/dist/dev/shardingsphere/KEYS >> KEYS
gpg --import KEYS
gpg --edit-key "${发布人的gpg用户名}"
  > trust

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5

  > save

然后进行gpg签名检查。

gpg --verify apache-shardingsphere-elasticjob-${RELEASE.VERSION}-src.zip.asc apache-shardingsphere-elasticjob-${RELEASE.VERSION}-src.zip
gpg --verify apache-shardingsphere-elasticjob-${RELEASE.VERSION}-lite-bin.tar.gz.asc apache-shardingsphere-elasticjob-${RELEASE.VERSION}-lite-bin.tar.gz
gpg --verify apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-executor-bin.tar.gz.asc apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-executor-bin.tar.gz
gpg --verify apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-scheduler-bin.tar.gz.asc apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-scheduler-bin.tar.gz

检查发布文件内容

对比源码包与Github上tag的内容差异

curl -Lo tag-${RELEASE.VERSION}.zip https://github.com/apache/shardingsphere-elasticjob/archive/${RELEASE.VERSION}.zip
unzip tag-${RELEASE.VERSION}.zip
unzip apache-shardingsphere-elasticjob-${RELEASE.VERSION}-src.zip
diff -r apache-shardingsphere-elasticjob-${RELEASE.VERSION}-src-release shardingsphere-elasticjob-${RELEASE.VERSION}

检查源码包的文件内容

  • 检查源码包是否包含由于包含不必要文件,致使tarball过于庞大
  • 存在LICENSENOTICE文件
  • NOTICE文件中的年份正确
  • 只存在文本文件,不存在二进制文件
  • 所有文件的开头都有ASF许可证
  • 能够正确编译,单元测试可以通过 (./mvnw -T 1C install)
  • 检查是否有多余文件或文件夹,例如空文件夹等

检查二进制包的文件内容

解压缩
apache-shardingsphere-elasticjob-${RELEASE.VERSION}-lite-bin.tar.gz
apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-executor-bin.tar.gz
apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-scheduler-bin.tar.gz
进行如下检查:

  • 存在LICENSENOTICE文件
  • NOTICE文件中的年份正确
  • 所有文本文件开头都有ASF许可证
  • 检查第三方依赖许可证:
    • 第三方依赖的许可证兼容
    • 所有第三方依赖的许可证都在LICENSE文件中声名
    • 依赖许可证的完整版全部在license目录
    • 如果依赖的是Apache许可证并且存在NOTICE文件,那么这些NOTICE文件也需要加入到版本的NOTICE文件中

发起投票

投票阶段

  1. ShardingSphere社区投票,发起投票邮件到dev@shardingsphere.apache.org。PMC需要先按照文档检查版本的正确性,然后再进行投票。
    经过至少72小时并统计到3个+1 PMC member票后,即可进入下一阶段的投票。

  2. 宣布投票结果,发起投票结果邮件到dev@shardingsphere.apache.org

投票模板

  1. ShardingSphere社区投票模板

标题:

[VOTE] Release Apache ShardingSphere ElasticJob-${RELEASE.VERSION}

正文:

Hello ShardingSphere Community,

This is a call for vote to release Apache ShardingSphere ElasticJob-${RELEASE.VERSION}

Release notes:
https://github.com/apache/shardingsphere-elasticjob/blob/master/RELEASE-NOTES.md

The release candidates:
https://dist.apache.org/repos/dist/dev/shardingsphere/elasticjob-${RELEASE.VERSION}/

Maven 2 staging repository:
https://repository.apache.org/content/repositories/${STAGING.REPOSITORY}/org/apache/shardingsphere/

Git tag for the release:
https://github.com/apache/shardingsphere-elasticjob/tree/${RELEASE.VERSION}/

Release Commit ID:
https://github.com/apache/shardingsphere-elasticjob/commit/xxxxxxxxxxxxxxxxxxxxxxx

Keys to verify the Release Candidate:
https://dist.apache.org/repos/dist/dev/shardingsphere/KEYS

Look at here for how to verify this release candidate:
https://shardingsphere.apache.org/community/en/contribute/release-elasticjob/

GPG user ID:
${YOUR.GPG.USER.ID}

The vote will be open for at least 72 hours or until necessary number of votes are reached.

Please vote accordingly:

[ ] +1 approve 

[ ] +0 no opinion
 
[ ] -1 disapprove with the reason

PMC vote is +1 binding, all others is +1 non-binding.

Checklist for reference:

[ ] Download links are valid.

[ ] Checksums and PGP signatures are valid.

[ ] Source code distributions have correct names matching the current release.

[ ] LICENSE and NOTICE files are correct for each ShardingSphere repo.

[ ] All files have license headers if necessary.

[ ] No compiled archives bundled in source archive.
  1. 宣布投票结果模板:

标题:

[RESULT][VOTE] Release Apache ShardingSphere ElasticJob-${RELEASE.VERSION}

正文:

We’ve received 3 +1 binding votes and one +1 non-binding vote:

+1 binding, xxx
+1 binding, xxx
+1 binding, xxx

+1 non-binding, xxx

Thank you everyone for taking the time to review the release and help us. 
I will process to publish the release and send ANNOUNCE.

完成发布

1. 将源码、二进制包以及KEYS从svn的dev目录移动到release目录

svn mv https://dist.apache.org/repos/dist/dev/shardingsphere/elasticjob-${RELEASE.VERSION} https://dist.apache.org/repos/dist/release/shardingsphere/ -m "transfer packages for elasticjob-${RELEASE.VERSION}"
svn delete https://dist.apache.org/repos/dist/release/shardingsphere/KEYS -m "delete KEYS"
svn cp https://dist.apache.org/repos/dist/dev/shardingsphere/KEYS https://dist.apache.org/repos/dist/release/shardingsphere/ -m "transfer KEYS for elasticjob-${RELEASE.VERSION}"

2. 在Apache Staging仓库找到ShardingSphere并点击Release

3. 合并Github的release分支到master, 合并完成后删除release分支

git checkout master
git merge origin/${RELEASE.VERSION}-release
git pull
git push origin master
git push --delete origin ${RELEASE.VERSION}-release
git branch -d ${RELEASE.VERSION}-release

4. 发布 Docker

4.1 准备工作

本地安装 Docker,并启动服务。

4.2 编译 Docker 镜像

git checkout ${RELEASE.VERSION}
cd ~/elasticjob/elasticjob-distribution/elasticjob-cloud-scheduler-distribution/
mvn clean package -Prelease,docker

4.3 给本地 Docker 镜像打标记

通过docker images查看到IMAGE ID,例如为:e9ea51023687

docker tag e9ea51023687 apache/shardingsphere-elasticjob-cloud-scheduler:latest
docker tag e9ea51023687 apache/shardingsphere-elasticjob-cloud-scheduler:${RELEASE.VERSION}

4.4 发布 Docker 镜像

docker login
docker push apache/shardingsphere-elasticjob-cloud-scheduler:latest
docker push apache/shardingsphere-elasticjob-cloud-scheduler:${RELEASE_VERSION}

4.5 确认发布成功

登录 Docker Hub 查看是否有发布的镜像

5. GitHub版本发布

GitHub Releases 页面的 ${RELEASE_VERSION} 版本上点击 Edit

编辑版本号及版本说明,并点击Publish release

6. 更新下载页面

等待并确认新的发布版本同步至 Apache 镜像后,更新如下页面:

https://shardingsphere.apache.org/elasticjob/current/en/downloads/

https://shardingsphere.apache.org/elasticjob/current/cn/downloads/

GPG签名文件和哈希校验文件的下载连接应该使用这个前缀:https://downloads.apache.org/shardingsphere/

最新版本中保留一个最新的版本。

7. 邮件通知版本发布完成

发送邮件到dev@shardingsphere.apache.organnounce@apache.org通知完成版本发布

通知邮件模板:

标题:

[ANNOUNCE] Apache ShardingSphere ElasticJob-${RELEASE.VERSION} available

正文:

Hi all,

Apache ShardingSphere Team is glad to announce the new release of Apache ShardingSphere ElasticJob-${RELEASE.VERSION}.

ElasticJob is a distributed scheduling solution consisting of two separate projects, ElasticJob-Lite and ElasticJob-Cloud.
Through the functions of flexible scheduling, resource management and job management, it creates a distributed scheduling solution suitable for Internet scenarios, and provides diversified job ecosystem through open architecture design. It uses a unified job API for each project. Developers only need code one time and can deploy at will.
ElasticJob became an Apache ShardingSphere Sub project on May 28 2020.

Download Links: https://shardingsphere.apache.org/elasticjob/current/en/downloads/

Release Notes: https://github.com/apache/shardingsphere-elasticjob/blob/master/RELEASE-NOTES.md

Website: http://shardingsphere.apache.org/elasticjob/

ShardingSphere-ElasticJob Resources:
- Issue: https://github.com/apache/shardingsphere-elasticjob/issues/
- Mailing list: dev@shardingsphere.apache.org
- Documents: https://shardingsphere.apache.org/elasticjob/current/en/overview/



- Apache ShardingSphere Team

ElasticJob-UI 发布指南

GPG设置

详情请参见发布指南

发布Apache Maven中央仓库

1. 设置settings.xml文件

将以下模板添加到 ~/.m2/settings.xml中,所有密码需要加密后再填入。
加密设置可参考这里

<settings>
  <servers>
    <server>
      <id>apache.snapshots.https</id>
      <username> <!-- APACHE LDAP 用户名 --> </username>
      <password> <!-- APACHE LDAP 加密后的密码 --> </password>
    </server>
    <server>
      <id>apache.releases.https</id>
      <username> <!-- APACHE LDAP 用户名 --> </username>
      <password> <!-- APACHE LDAP 加密后的密码 --> </password>
    </server>
  </servers>
</settings>

2. 更新版本说明

https://github.com/apache/shardingsphere-elasticjob-ui/blob/master/RELEASE-NOTES.md

3. 创建发布分支

假设从github下载的ElasticJob-UI源代码在~/elasticjob-ui/目录;假设即将发布的版本为${RELEASE.VERSION}
创建${RELEASE.VERSION}-release分支,接下来的操作都在该分支进行。

## ${name}为源码所在分支,如:master,dev-4.x
git clone --branch ${name} https://github.com/apache/shardingsphere-elasticjob-ui.git ~/elasticjob-ui
cd ~/elasticjob-ui/
git pull
git checkout -b ${RELEASE.VERSION}-release
git push origin ${RELEASE.VERSION}-release

4. 发布预校验

cd ~/elasticjob-ui
mvn release:prepare -Prelease -Darguments="-DskipTests" -DautoVersionSubmodules=true -DdryRun=true -Dusername=${Github用户名}

-Prelease: 选择release的profile,这个profile会打包所有源码、jar文件以及ElasticJob-UI的可执行二进制包。

-DautoVersionSubmodules=true:作用是发布过程中版本号只需要输入一次,不必为每个子模块都输入一次。

-DdryRun=true:演练,即不产生版本号提交,不生成新的tag。

5. 准备发布

首先清理发布预校验本地信息。

cd ~/elasticjob-ui
mvn release:clean

然后准备执行发布。

cd ~/elasticjob-ui
mvn release:prepare -Prelease -Darguments="-DskipTests" -DautoVersionSubmodules=true -DpushChanges=false -Dusername=${Github用户名}

和上一步演练的命令基本相同,去掉了-DdryRun=true参数。

-DpushChanges=false:不要将修改后的版本号和tag自动提交至Github。

将本地文件检查无误后,提交至github。

git push origin ${RELEASE.VERSION}-release
git push origin --tags

6. 部署发布

cd ~/elasticjob-ui
mvn release:perform -Prelease -Darguments="-DskipTests" -DautoVersionSubmodules=true -Dusername=${Github用户名}

发布Apache SVN仓库

1. 检出shardingsphere发布目录

如无本地工作目录,则先创建本地工作目录。

mkdir -p ~/ss_svn/dev/
cd ~/ss_svn/dev/

创建完毕后,从Apache SVN检出shardingsphere发布目录。

svn --username=${APACHE LDAP 用户名} co https://dist.apache.org/repos/dist/dev/shardingsphere
cd ~/ss_svn/dev/shardingsphere

2. 添加gpg公钥

仅第一次部署的账号需要添加,只要KEYS中包含已经部署过的账户的公钥即可。

gpg -a --export ${GPG用户名} >> KEYS

3. 将待发布的内容添加至SVN目录

创建版本号目录。

mkdir -p ~/ss_svn/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION}
cd ~/ss_svn/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION}

将源码包和二进制包添加至SVN工作目录。

cp -f ~/elasticjob-ui/shardingsphere-elasticjob-ui-distribution/shardingsphere-elasticjob-ui-src-distribution/target/*.zip ~/ss_svn/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION}
cp -f ~/elasticjob-ui/shardingsphere-elasticjob-ui-distribution/shardingsphere-elasticjob-ui-src-distribution/target/*.zip.asc ~/ss_svn/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION}
cp -f ~/elasticjob-ui/shardingsphere-elasticjob-ui-distribution/shardingsphere-elasticjob-lite-ui-bin-distribution/target/*.tar.gz ~/ss_svn/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION}
cp -f ~/elasticjob-ui/shardingsphere-elasticjob-ui-distribution/shardingsphere-elasticjob-lite-ui-bin-distribution/target/*.tar.gz.asc ~/ss_svn/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION}
cp -f ~/elasticjob-ui/shardingsphere-elasticjob-ui-distribution/shardingsphere-elasticjob-cloud-ui-bin-distribution/target/*.tar.gz ~/ss_svn/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION}
cp -f ~/elasticjob-ui/shardingsphere-elasticjob-ui-distribution/shardingsphere-elasticjob-cloud-ui-bin-distribution/target/*.tar.gz.asc ~/ss_svn/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION}

4. 生成文件签名

shasum -a 512 apache-shardingsphere-elasticjob-${RELEASE.VERSION}-ui-src.zip > apache-shardingsphere-elasticjob-${RELEASE.VERSION}-ui-src.zip.sha512
shasum -b -a 512 apache-shardingsphere-elasticjob-${RELEASE.VERSION}-lite-ui-bin.tar.gz > apache-shardingsphere-elasticjob-${RELEASE.VERSION}-lite-ui-bin.tar.gz.sha512
shasum -b -a 512 apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-ui-bin.tar.gz > apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-ui-bin.tar.gz.sha512

5. 提交Apache SVN

cd ~/ss_svn/dev/shardingsphere/
svn add elasticjob-ui-${RELEASE.VERSION}
svn --username=${APACHE LDAP 用户名} commit -m "release elasticjob-ui-${RELEASE.VERSION}"

检查发布结果

检查sha512哈希

shasum -c apache-shardingsphere-elasticjob-${RELEASE.VERSION}-ui-src.zip.sha512
shasum -c apache-shardingsphere-elasticjob-${RELEASE.VERSION}-lite-ui-bin.tar.gz.sha512
shasum -c apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-ui-bin.tar.gz.sha512

检查gpg签名

首先导入发布人公钥。从svn仓库导入KEYS到本地环境。(发布版本的人不需要再导入,帮助做验证的人需要导入,用户名填发版人的即可)

curl https://dist.apache.org/repos/dist/dev/shardingsphere/KEYS >> KEYS
gpg --import KEYS
gpg --edit-key "${发布人的gpg用户名}"
  > trust

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5

  > save

然后进行gpg签名检查。

gpg --verify apache-shardingsphere-elasticjob-${RELEASE.VERSION}-ui-src.zip.asc apache-shardingsphere-elasticjob-${RELEASE.VERSION}-ui-src.zip
gpg --verify apache-shardingsphere-elasticjob-${RELEASE.VERSION}-lite-ui-bin.tar.gz.asc apache-shardingsphere-elasticjob-${RELEASE.VERSION}-lite-ui-bin.tar.gz
gpg --verify apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-ui-bin.tar.gz.asc apache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-ui-bin.tar.gz

检查发布文件内容

对比源码包与Github上tag的内容差异

curl -Lo tag-${RELEASE.VERSION}.zip https://github.com/apache/shardingsphere-elasticjob-ui/archive/${RELEASE.VERSION}.zip
unzip tag-${RELEASE.VERSION}.zip
unzip apache-shardingsphere-elasticjob-${RELEASE.VERSION}-ui-src.zip
diff -r apache-shardingsphere-elasticjob-${RELEASE.VERSION}-ui-src shardingsphere-elasticjob-ui-${RELEASE.VERSION}

检查源码包的文件内容

  • 检查源码包是否包含由于包含不必要文件,致使tarball过于庞大
  • 存在LICENSENOTICE文件
  • NOTICE文件中的年份正确
  • 只存在文本文件,不存在二进制文件
  • 所有文件的开头都有ASF许可证
  • 能够正确编译,单元测试可以通过 (./mvnw -T 1C install)
  • 检查是否有多余文件或文件夹,例如空文件夹等

检查二进制包的文件内容

解压缩apache-shardingsphere-elasticjob-${RELEASE.VERSION}-lite-ui-bin.tar.gzapache-shardingsphere-elasticjob-${RELEASE.VERSION}-cloud-ui-bin.tar.gz
进行如下检查:

  • 存在LICENSENOTICE文件
  • NOTICE文件中的年份正确
  • 所有文本文件开头都有ASF许可证
  • 检查第三方依赖许可证:
    • 第三方依赖的许可证兼容
    • 所有第三方依赖的许可证都在LICENSE文件中声名
    • 依赖许可证的完整版全部在license目录
    • 如果依赖的是Apache许可证并且存在NOTICE文件,那么这些NOTICE文件也需要加入到版本的NOTICE文件中

发起投票

投票阶段

  1. ShardingSphere社区投票,发起投票邮件到dev@shardingsphere.apache.org。PMC需要先按照文档检查版本的正确性,然后再进行投票。
    经过至少72小时并统计到3个+1 PMC member票后,即可进入下一阶段的投票。

  2. 宣布投票结果,发起投票结果邮件到dev@shardingsphere.apache.org

投票模板

  1. ShardingSphere社区投票模板

标题:

[VOTE] Release Apache ShardingSphere ElasticJob UI ${RELEASE.VERSION}

正文:

Hello ShardingSphere Community,

This is a call for vote to release Apache ShardingSphere ElasticJob UI version ${RELEASE.VERSION}

Release notes:
https://github.com/apache/shardingsphere-elasticjob-ui/blob/master/RELEASE-NOTES.md

The release candidates:
https://dist.apache.org/repos/dist/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION}/

Git tag for the release:
https://github.com/apache/shardingsphere-elasticjob-ui/tree/${RELEASE.VERSION}/

Release Commit ID:
https://github.com/apache/shardingsphere-elasticjob-ui/commit/xxxxxxxxxxxxxxxxxxxxxxx

Keys to verify the Release Candidate:
https://dist.apache.org/repos/dist/dev/shardingsphere/KEYS

Look at here for how to verify this release candidate:
https://shardingsphere.apache.org/community/en/contribute/release-elasticjob-ui/

GPG user ID:
${YOUR.GPG.USER.ID}

The vote will be open for at least 72 hours or until necessary number of votes are reached.

Please vote accordingly:

[ ] +1 approve 

[ ] +0 no opinion
 
[ ] -1 disapprove with the reason

PMC vote is +1 binding, all others is +1 non-binding.

Checklist for reference:

[ ] Download links are valid.

[ ] Checksums and PGP signatures are valid.

[ ] Source code distributions have correct names matching the current release.

[ ] LICENSE and NOTICE files are correct for each ShardingSphere repo.

[ ] All files have license headers if necessary.

[ ] No compiled archives bundled in source archive.
  1. 宣布投票结果模板:

标题:

[RESULT][VOTE] Release Apache ShardingSphere ElasticJob UI ${RELEASE.VERSION}

正文:

We’ve received 3 +1 binding votes and one +1 non-binding vote:

+1 binding, xxx
+1 binding, xxx
+1 binding, xxx

+1 non-binding, xxx

Thank you everyone for taking the time to review the release and help us. 
I will process to publish the release and send ANNOUNCE.

完成发布

1. 将源码、二进制包以及KEYS从svn的dev目录移动到release目录

svn mv https://dist.apache.org/repos/dist/dev/shardingsphere/elasticjob-ui-${RELEASE.VERSION} https://dist.apache.org/repos/dist/release/shardingsphere/ -m "transfer packages for elasticjob-ui-${RELEASE.VERSION}"
svn delete https://dist.apache.org/repos/dist/release/shardingsphere/KEYS -m "delete KEYS"
svn cp https://dist.apache.org/repos/dist/dev/shardingsphere/KEYS https://dist.apache.org/repos/dist/release/shardingsphere/ -m "transfer KEYS for elasticjob-ui-${RELEASE.VERSION}"

2. 合并Github的release分支到master, 合并完成后删除release分支

git checkout master
git merge origin/${RELEASE.VERSION}-release
git pull
git push origin master
git push --delete origin ${RELEASE.VERSION}-release
git branch -d ${RELEASE.VERSION}-release

3. 发布 Docker (cloud-ui)

3.1 准备工作

本地安装 Docker,并启动服务。

3.2 编译 Docker 镜像

git checkout ${RELEASE.VERSION}
cd ~/elasticjob-ui/shardingsphere-elasticjob-ui-distribution/shardingsphere-elasticjob-cloud-ui-bin-distribution/
mvn clean package -Prelease,docker

3.3 给本地 Docker 镜像打标记

通过docker images查看到IMAGE ID,例如为:e9ea51023687

docker tag e9ea51023687 apache/shardingsphere-elasticjob-cloud-ui:latest
docker tag e9ea51023687 apache/shardingsphere-elasticjob-cloud-ui:${RELEASE.VERSION}

3.4 发布Docker镜像

docker push apache/shardingsphere-elasticjob-cloud-ui:latest
docker push apache/shardingsphere-elasticjob-cloud-ui:${RELEASE_VERSION}

3.5 确认发布成功

登录 Docker Hub 查看是否有发布的镜像

4. 发布 Docker (lite-ui)

4.1 准备工作

本地安装 Docker,并启动服务。

4.2 编译 Docker 镜像

cd ~/elasticjob-ui/shardingsphere-elasticjob-ui-distribution/shardingsphere-elasticjob-lite-ui-bin-distribution/
mvn clean package -Prelease,docker

4.3 给本地 Docker 镜像打标记

通过docker images查看到IMAGE ID,例如为:e9ea51023687

docker tag e9ea51023687 apache/shardingsphere-elasticjob-lite-ui:latest
docker tag e9ea51023687 apache/shardingsphere-elasticjob-lite-ui:${RELEASE.VERSION}

4.4 发布Docker镜像

docker login
docker push apache/shardingsphere-elasticjob-lite-ui:latest
docker push apache/shardingsphere-elasticjob-lite-ui:${RELEASE_VERSION}

4.5 确认发布成功

登录 Docker Hub 查看是否有发布的镜像

5. GitHub 版本发布

GitHub Releases 页面的 shardingsphere-elasticjob-ui-${RELEASE_VERSION} 版本上点击 Edit

编辑版本号及版本说明,并点击Publish release

6. 更新下载页面

等待并确认新的发布版本同步至 Apache 镜像后,更新如下页面:

https://shardingsphere.apache.org/elasticjob/current/en/downloads/

https://shardingsphere.apache.org/elasticjob/current/cn/downloads/

GPG签名文件和哈希校验文件的下载连接应该使用这个前缀: https://downloads.apache.org/shardingsphere/

最新版本中保留一个最新的版本。

7. 邮件通知版本发布完成

发送邮件到dev@shardingsphere.apache.organnounce@apache.org通知完成版本发布

通知邮件模板:

标题:

[ANNOUNCE] Apache ShardingSphere ElasticJob UI ${RELEASE.VERSION} available

正文:

Hi all,

Apache ShardingSphere Team is glad to announce the new release of Apache ShardingSphere ElasticJob UI ${RELEASE.VERSION}.

ElasticJob is a distributed scheduling solution consisting of two separate projects, ElasticJob-Lite and ElasticJob-Cloud.
Through the functions of flexible scheduling, resource management and job management, it creates a distributed scheduling solution suitable for Internet scenarios, and provides diversified job ecosystem through open architecture design. It uses a unified job API for each project. Developers only need code one time and can deploy at will.
ElasticJob became an Apache ShardingSphere Sub project on May 28 2020.

Download Links: https://shardingsphere.apache.org/elasticjob/current/en/downloads/

Release Notes: https://github.com/apache/shardingsphere-elasticjob-ui/blob/master/RELEASE-NOTES.md

Website: http://shardingsphere.apache.org/elasticjob/

ShardingSphere-ElasticJob Resources:
- Issue: https://github.com/apache/shardingsphere-elasticjob-ui/issues/
- Mailing list: dev@shardingsphere.apache.org
- Documents: https://shardingsphere.apache.org/elasticjob/current/en/overview/



- Apache ShardingSphere Team

2FA

双因素认证(2FA)

双因子验证(2FA)是指结合密码以及实物(信用卡、SMS手机、令牌或指纹等生物标志)两种条件对用户进行认证的方法。
为保证提交者账户的安全,我们需要您在GitHub上启用2FA来验证登录用户、并贡献代码。

具体内容可参考2FA

注意:若您不启用2FA,您将会从本项目中除名,并且无法访问我们的仓库以及来自我们私有仓库的fork仓库。

在GitHub上启用2FA

具体操作,请参考使用TOTP启用双因素认证

当您开启2FA验证后,您需要使用用户名/密码 + 手机认证码的方式来登录GitHub。

提示:若无法通过页面链接下载对应APP,可在手机的应用市场或是APP Store里搜索并下载Google Authenticator。

如何提交代码

当启用2FA认证后,您需要生成私有访问Token来进行git提交等操作。此时,您将使用用户名 + 私有访问Token 来代替 用户名 + 密码的方式
进行代码的提交。

具体操作,请参考创建私有Token

签署 iCLA 指南

Apache ICLA 签署流程指南

Apache CLA 全称 Apache Contributor License Agreement,签署ICLA的目的是定义向ASF贡献的文档,保护知识产权,避免后续法律纠纷。ICLA在官方存档后生效,贡献者方可参与Apache项目。

当我们需要签署ICLA时步骤如下:

1. 打开链接 官网Licenses 在Contributor License Agreements 下找到CLAs并进入页面。

2. 在页面上方我们可以看到两个下载链接,选择ICLA(个人CLA)并下载文件。

3. 打开PDF,ICLA需要填写的是两个部分,均需要全英文填写。

注意事项:

  • 姓名需要填写拼音,姓与名之间空一格,首字母均为大写,名在前姓氏在后。
  • Committer相关的签署,则preferred Apache id(s)是必填项。

4.文件最下方的署名。
官方只接受手写或者gpg签名,这里只建议用手写的方式,可以打印文件进行手写签名或者使用电子笔进行签字。

提交文件

  • 如果您是新Committer,请扫描签署后文件的所有页合并到一个PDF的文档,发送email 到 secretary@apache.org
  • 其他情况,请联系需要您签署ICLA文档的负责人。

提交者选举流程指南

提交者选举流程

1. 在 @private 邮件列表讨论并投票,投票由现有的 PMC 成员发起,邮件内容主要陈述提名者的活动和社区贡献。

例如:

To:private@shardingsphere.apache.org

Title: [VOTE] New committer: (提名者)

Content:

Hi, everyone

This is ^a formal vote^ about inviting (提名者) as our new committer. 
He/She really made an effort to improve ShardingSphere Parser and fix many issues. 
The following links will direct you to his/her work.

https://github.com/apache/shardingsphere/pull/6319
https://github.com/apache/shardingsphere/pull/6293
https://github.com/apache/shardingsphere/pull/6259
https://github.com/apache/shardingsphere/pull/6211

[^ means these words are subject to change in different case]

2. 等待 3*24h 社区 Committe r投票。

3. PMC 成员总结社区投票结果并发布邮件。

例如:

To: private@shardingsphere.apache.org

Title: [RESULT] [VOTE] New committer: (提名者)

Content:

Hi all PMCs, 

I am glad to receive your votes, and the voting result is,
6   +1 votes, 0   +/-1 votes, 0   -1 votes

Therefore, I will send the invitation to (提名者).

4. 如果投票通过,对提名者发布邀请函并抄送 @private 邮件列表给发送邀请函。

To: (提名者邮箱)

cc: private@shardingsphere.apache.org

Title: Invitation to become ShardingSphere committer: (提名者)

Content:

Hello (提名者),

The ShardingSphere Project Management Committee (PMC) hereby offers you committer privileges to the project. These privileges are offered on the understanding that you'll use them reasonably and with common sense. We like to work on trust
rather than unnecessary constraints.
Being a committer enables you to more easily make changes without needing to go through the patch submission process.
Being a committer does not require you to participate any more than you already do. It does tend to make one even more committed.  You will probably find that you spend more time here.
Of course, you can decline and instead remain as a contributor, participating as you do now.
A. This personal invitation is a chance for you to accept or decline in private.  Either way, please let us know in reply to the private@shardingsphere.apache.org 
address only.
B. If you accept, the next step is to register an iCLA:
    1. Details of the iCLA and the forms are found through this link: http://www.apache.org/licenses/#clas

    2. Instructions for its completion and return to the Secretary of the ASF are found at http://www.apache.org/licenses/#submitting

    3. When you transmit the completed iCLA, request to notify the Apache ShardingSphere and choose a unique Apache id. Look to see if your preferred id is already taken at http://people.apache.org/committer-index.html        
This will allow the Secretary to notify the PMC when your iCLA has been recorded.
When recording of your iCLA is noticed, you will receive a follow-up message with the next steps for establishing you as a committer.

Best wishes,
(PMC)

5. 准 Committer 回复邀请函内容,回复表达同意与感谢。

6. PMC 做出回复。

Hi (提名者),

Welcome! Here are the next steps. After that we will make an announcement to the shardingsphere-dev list.

You need to send a Contributor License Agreement to the ASF. Normally you would send an Individual CLA. If you also make contributions done in work time or using work resources then see the Corporate CLA. Ask us if you have any issues. 
http://www.apache.org/licenses/#clas

You need to choose a preferred ASF user name and alternatives. In order to ensure it is available you can view a list of taken ids at
http://people.apache.org/committer-index.html
Please notify us when you have submitted the CLA and by what means you did so. This will enable us to monitor its progress.

We will arrange for your Apache user account when the CLA has been recorded.

After that is done, please make follow-up replies to the shardingsphere-dev list. We generally discuss everything there and keep the private@shardingsphere.apache.org list for occasional matters which must be private.

The developer section of the website describes the roles and provides other resources:
http://www.apache.org/foundation/how-it-works.html
http://www.apache.org/dev/

The incubator also has some useful information for new committers in incubating projects:
http://incubator.apache.org/guides/committer.html

Just as before you became a committer, participation in any ASF community requires adherence to the ASF Code of Conduct:
https://www.apache.org/foundation/policies/conduct.html

Here is the guideline for all of the ShardingSphere committers:
https://shardingsphere.apache.org/community/en/contribute/committer/

7. 准 Committer 签署 iCLA 具体步骤参考签署iCLA指南

8. 等待 Secretary 通知创建账户。

9. PMC 添加新 Committer 到 roster

10. 新 Committer 开通 github 权限,完成Setup内容。

11. PMC 在社区宣布并欢迎新的 Committer 加入。

To: dev@shardingsphere.apache.org

Title: [ANNOUNCE] New committer: (提名者)

Content:

Hi community,

The Project Management Committee (PMC) for Apache ShardingSphere
has invited (提名者) to become a committer and we are pleased 
to announce that he has accepted.

(提名者) is active in ShardingSphere community, hope see your further interactions with the community! 

Thanks for your contributions.

12. 新 Commiter 更新提交者名单

13. 如果进行 PMC 选举,需额外增加一个步骤。由投票发起人发邮件到 board@apache.org

The Apache ShardingSphere project proposes to invite (提名者) to join the PMC.
The vote result is available here:
(投票详情链接)

Thank you,
(发起人)
京ICP备2021015875号