-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add changelog entry for 0.4.0 #752
Conversation
adombeck
commented
Jan 23, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some suggestions and points of discussion for us...
debian/changelog
Outdated
@@ -1,3 +1,15 @@ | |||
authd (0.4.0) noble; urgency=medium |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When updating the changelog, we usually target the latest Ubuntu version (which, in this case, would be Plucky). To release this to Noble, we must first release it to the current development release. You can read a bit more about it here!
However, since this is not going to the archive yet (AFAIK), there's an argument to keep the UNRELEASED
tag there instead and then adjusting it when build the source package to upload to the PPA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, ideally I always prefer to have UNRELEASED
in the commit that updates the cahngelog, then at changelog finalize time (dch -r "" --distribution noble && git commit -m "Upload to noble" debian/changelog && gbp buildpackage --git-tag-only --git-ignore-new
) you set the version, depending on whether the package goes to noble or plucky or anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When updating the changelog, we usually target the latest Ubuntu version (which, in this case, would be Plucky).
Oh ok, then the 0.3.7 release also should have targeted Plucky 😬
However, since this is not going to the archive yet (AFAIK), there's an argument to keep the UNRELEASED tag there instead and then adjusting it when build the source package to upload to the PPA.
Yeah so since we're uploading to the PPA, the target release doesn't matter at all, right? In that case I don't really care what we set it to. In all previous releases it was set to noble though.
Yeah, ideally I always prefer to have UNRELEASED in the commit that updates the cahngelog, then at changelog finalize time (dch -r "" --distribution noble && git commit -m "Upload to noble" debian/changelog && gbp buildpackage --git-tag-only --git-ignore-new) you set the version, depending on whether the package goes to noble or plucky or anything.
That makes sense but doesn't really correspond to our current process, because we only update the changelog right before the release, at which point we can just set the target release right away, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So are you both fine with me changing the target release to Plucky?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And should I update the 0.3.7 changelog entry as well or should I leave it set to Noble?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per targeting plucky by default, I'm fine, but we've still to update the packaging side as per plucky changes (I've already #738, but that's not enough as there are further changes I'm preparing a branch for.
That makes sense but doesn't really correspond to our current process, because we only update the changelog right before the release, at which point we can just set the target release right away, right?
Still we should keep it two separate commits for two reasons:
- Since we're effectively branching (at least on packaging side), in order to backport its easy to have an update-changelog commit we can merge with in the noble branch.
- In the debian world the signature on the upload changelog is like the stamp on what gets uploaded.
As per the old release, keep it as it is... I think it makes sense to start targeting the devel release now since that's the process we'll have to do anyways soon when authd will be in the archive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
0505b1a
to
0de33b9
Compare
To print the updated Go dependencies: GIT_REF=0.3.7 GIT_PAGER=less git diff "$GIT_REF" go.mod | \ grep -e '^\+\s' -e '^+toolchain' | \ sed -e 's/^\+\t/- /g' -e 's/^\+toolchain /- toolchain /g' To print the updated Rust dependencies: GIT_REF=0.3.7 CURRENT_GIT_REF=$(git rev-parse --abbrev-ref HEAD) tempdir=$(mktemp -d) old_versions_file="${tempdir}/old-versions.txt" new_versions_file="${tempdir}/new-versions.txt" git checkout -q "$GIT_REF" cargo metadata --format-version 1 --no-deps | \ jq -r '.packages[] | .dependencies[]? | "\(.name) \(.req)"' \ > "${new_versions_file}" git checkout -q "${CURRENT_GIT_REF}" cargo metadata --format-version 1 --no-deps | \ jq -r '.packages[] | .dependencies[]? | "\(.name) \(.req)"' \ > "${old_versions_file}" comm -13 <(sort "${old_versions_file}") <(sort "${new_versions_file}") | \ sed 's/^/- /g' rm -rf "$tempdir"
0de33b9
to
f3843c8
Compare
e54f917
to
f8afa8a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for addressing the comments.
Ps.: Don't forget to tag the repo after this is merged to main.