github-tools / github-tools/github-release-notes
Incorrect logic in release note creation
- 主要语言
- JavaScript
- 星标
- 897
- 派生
- 313
- PR 合并指标
- 30 天内没有已合并 PR
描述
Hi,
I have used gren for both creating changelog file and generating release notes on the GH releases and have the same wrong results in both cases:
```
# Changelog
## v1.0.7 (29/09/2020)
*No changelog for this release.*
---
## v1.0.6 (29/09/2020)
*No changelog for this release.*
---
## v1.0.5 (29/09/2020)
*No changelog for this release.*
---
## v1.0.4 (29/09/2020)
*No changelog for this release.*
---
## v1.0.3 (29/09/2020)
*No changelog for this release.*
---
## v1.0.2 (29/09/2020)
*No changelog for this release.*
---
## v1.0.1 (29/09/2020)
*No changelog for this release.*
---
## v1.0.0 (29/09/2020)
- List of all the 95 PRs we have.
```
So instead of spreading the 95 PRs in their correct releases, they have all been linked to v1.0.0 (which should just have a few).
I guess this is because the tags/releases have not been created at the time of the commit they are referring to. They have all been created today Sep 29th 2020, but each of them correctly points to the right sha1.
If that is the case, I think that being time-based is not a very robust approach, however it should at least be based on the **date of the commit** the tag is referring to and not the tag's date.
贡献指南
调研方向
首先,使用在目标提交之后创建的标签,复现 issue 中描述的 changelog 和 GitHub release 输出。检查 release note 生成的入口点,以及它如何确定每个 pull request 属于哪个 release。完成标准是:历史 pull request 根据所引用提交的日期或标签目标进行分配,而不是根据标签创建日期进行分配,并为此场景提供覆盖。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- javascript
- 领域
- release
- Issue 类型
- 缺陷
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 活跃度
- 停滞
- 描述清晰度
- 基本清楚
- 新手友好度
- 42/100