Update changelog script #4719
Update changelog script #4719
Conversation
aaruni96
added
release notes: not needed
|
Result at #4720 |
|
|
||
| #startdate = get_tag_date(basetag) | ||
| # HACK HACK HACK FIXME TODO WORKAROUND | ||
| startdate = "2024-10-30" |
There was a problem hiding this comment.
I don't think we are quite yet ready to remove this workaround, are we? GitHub releases right now are not enough to tell us when the branch point was.
The two options I see right now are:
- we do a full cone of the Oscar repo after all and use
git merge-base PREVTAG CURRENT_BRANCH(withCURRENT_BRANCHeithermasterorrelease-X.YI guess) - we add a hardcoded list of relevant dates, and/or keep this one hardcoded date.
There was a problem hiding this comment.
Sorry, you are right.
My changes work for now, because our patch release process is manually backporting stuff since last release. So, it should still be fine for 1.3.1, (and other 1.3.x), but not 1.4.0 (or 2.0), I think.
There was a problem hiding this comment.
We bump the version in the readme everytime we branch off a release branch ( #4642 ). We can either label this with a new label like version-bump, or we can search for this (the name is quite predictable : gh pr list -S "Version 1.{current-minor}.0-dev" -s "merged" )
Then we can grab the date of whenever that PR was merged ?
Co-authored-by: Max Horn <[email protected]>
| @@ -20,7 +20,7 @@ | |||
|
|
|||
|
|
|||
| def usage(name: str) -> None: | |||
| print(f"Usage: `{name} [NEWVERSION]`") | |||
| print(f"Usage: `{name} [NEWVERSION] [OLDVERSION]`") | |||
There was a problem hiding this comment.
I don't understand why this needs to be added, what problem does it solve?
There was a problem hiding this comment.
This would allow us to specify old version, so the script can find release date of old version (which in my head, does not necessarily need to be previously released version).
For example, lets say we release 1.3.1, and then 1.4, and then want to backport some critical thing to 1.3.2. Then the usage of the script like ./release_notes.py 1.3.2 1.3.1 would let us specify "only the pull requests closed since the release of 1.3.1, which have the backport 1.3.x label"
This is of course, only future proofing (and seemed like a great idea when I was changing .github/workflows/changelog.yml to include the optional version specifier input.
|
The only thing that is currently holding back the 1.3.1 release is this PR (and the associated changelog PR produced by this script). Since there are still open issues with the changelog script which aren't addressed in this PR, should we just merge the changelog PR (#4720), and remove the backports label from this PR ? |
I would be in favor of this. |
@fingolfin It would be great if we could get a decision on this, as then Aaruni could proceed with the 1.3.1 release |
thofma's and my point was to NOT merge this, but instead remove the backport label |
lgoettgens
dismissed
fingolfin’s stale review
just talked and we don't merge this right now
just talked with @fingolfin on gather, and this is how we would proceed. so @aaruni96 you can go ahead with the changelog and release |
Updates the changelog workflow to allow for an optional basetag. Also pushes change log stuff to ignore list for CI