Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
镜像
Python_Packaging_Authority
pip
提交
bad0b13b
P
pip
项目概览
镜像
/
Python_Packaging_Authority
/
pip
12 个月 前同步成功
通知
0
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
P
pip
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
bad0b13b
编写于
4月 24, 2018
作者:
P
Paul Moore
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Document our deprecation policy, plus a few other process details
上级
7b1f2a06
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
38 addition
and
1 deletion
+38
-1
docs/development.rst
docs/development.rst
+37
-1
news/deprecation.process
news/deprecation.process
+1
-0
未找到文件。
docs/development.rst
浏览文件 @
bad0b13b
...
@@ -33,6 +33,13 @@ push the changes to your fork::
...
@@ -33,6 +33,13 @@ push the changes to your fork::
Open Pull Requests page at https://github.com/yourname/pip/pulls and
Open Pull Requests page at https://github.com/yourname/pip/pulls and
click "New pull request". That's it.
click "New pull request". That's it.
Pull requests should be self-contained, and limited in scope. Before being
merged, a pull request must be reviewed, and keeping individual PRs limited
in scope makes this far easier. In particular, pull requests must not be
treated as "feature branches", with ongoing development work happening
within the PR. Instead, the feature should be broken up into smaller,
independent parts which can be reviewed and merged individually.
Automated Testing
Automated Testing
=================
=================
...
@@ -140,7 +147,7 @@ updating deprecation policy, etc.
...
@@ -140,7 +147,7 @@ updating deprecation policy, etc.
Release Cadence
Release Cadence
===============
===============
The pip project has a release cadence of releasing whatever is on `
master
`
The pip project has a release cadence of releasing whatever is on `
`master`
`
every 3 months. This gives users a predictable pattern for when releases
every 3 months. This gives users a predictable pattern for when releases
are going to happen and prevents locking up improvements for fixes for long
are going to happen and prevents locking up improvements for fixes for long
periods of time, while still preventing massively fracturing the user base
periods of time, while still preventing massively fracturing the user base
...
@@ -155,6 +162,35 @@ The release manager may, at their discretion, choose whether or not there
...
@@ -155,6 +162,35 @@ The release manager may, at their discretion, choose whether or not there
will be a pre-release period for a release, and if there is may extend that
will be a pre-release period for a release, and if there is may extend that
period into the next month if needed.
period into the next month if needed.
Because releases are made direct from the ``master`` branch, it is essential
that ``master`` is always in a releasable state. It is acceptable to merge
PRs that partially implement a new feature, but only if the partially
implemented version is usable in that state (for example, with reduced
functionality or disabled by default). In the case where a merged PR is found
to need extra work before being released, the release manager always has the
option to back out the partial change prior to a release. The PR can then be
reworked and resubmitted for the next release.
Deprecation Policy
==================
Any change to pip that removes or significantly alters user-visible behaviour that
is described in the pip documentation will be deprecated for a minimum of one
released version before the change occurs. Deprecation will take the form of a
warning being issued by pip when the feature is used. Longer deprecation periods,
or deprecation warnings for behaviour changes that would not normally be covered
by this policy, are also possible depending on circumstances, but this is at the
discretion of the pip developers.
Note that the documentation is the sole reference for what counts as agreed
behaviour. If something isn't explicitly mentioned in the documentation, it can
be changed without warning, or any deprecation period, in a pip release.
However, we are aware that the documentation isn't always complete - PRs that
document existing behaviour with the intention of covering that behaviour with
the above deprecation process are always acceptable, and will be considered on
their merits.
Release Process
Release Process
===============
===============
...
...
news/deprecation.process
0 → 100644
浏览文件 @
bad0b13b
Formally document our deprecation process
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录