github-tools / github-tools/github-release-notes

Incorrect logic in release note creation

未關閉
#282 3 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
enhancement
主要語言
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.

貢獻指南

開啟貢獻指南

研究方向

Start by reproducing the changelog and GitHub release output described in the issue with tags created after their target commits. Inspect the release-note generation entry point and how it determines which release contains each pull request. Done means historical pull requests are assigned using the referenced commit date or tag target rather than the tag creation date, with coverage for this scenario.

由索引模型根據 Issue 內容生成。

評估

技術堆疊
javascript
領域
release
Issue 類型
缺陷
難度
3/5
預估耗時
1-2 天
活躍度
停滯
描述清晰度
基本清楚
新手友好度
42/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。