Docs: Link to rendered GitHub AsciiDoc for release notes #2117
Conversation
dscho
left a comment
dscho
left a comment
There was a problem hiding this comment.
Thank you for working on this @gaurav219! A few changes are necessary before it can be merged, though.
| config["params"] = {} if config["params"].nil? | ||
| config["params"]["latest_version"] = version | ||
| config["params"]["latest_relnote_url"] = "https://github.com/git/git/raw/HEAD/Documentation/RelNotes/#{version}.adoc" | ||
| config["params"]["latest_relnote_url"] = "https://gitlab.com/git-scm/git/-/blob/v2.52.0/Documentation/RelNotes/#{version}.adoc" |
There was a problem hiding this comment.
This will break for later versions: You are hard-coding v2.52.0 as the revision in which to look for the release notes. Naturally, this revision only contains the release notes leading up to that version, and once, say, v2.52.1 or v2.53.0 come out, the updated link will 404 because the v2.52.0 revision won't magically change to include the release notes for those new versions.
You need to either replace v2.52.0 by v#{version} (and understand what that is doing), or do the equivalent from before, i.e. point to https://gitlab.com/git-scm/git/-/blob/HEAD/Documentation/RelNotes/2.52.0.adoc.
There was a problem hiding this comment.
I understand. Thanks for explaining in detail. I will make the changes now.
This might be a dumb questions, but, should i rebase/amend and modify the commit with the new changes?
Or should i just add a new commit to my branch?
There was a problem hiding this comment.
I much prefer amending to leaving incorrect commits as-are.
| config["params"]["latest_release_date"] = date.strftime("%Y-%m-%d") | ||
| yaml = YAML.dump(config).gsub(/ *$/, "") | ||
| File.write("hugo.yml", yaml) | ||
| File.write("hugo.yml", yaml) |
There was a problem hiding this comment.
Please lose this white-space only change that is totally unrelated to what the commit message says.
Speaking of the commit message: It really wants to see some love. From looking at the oneliner "Docs: Link to rendered GitHub AsciiDoc for release notes", I am almost 100% certain that even you, in 6 months from now, would have trouble to deduce why you made the change. But that's vital information! And the only spot where you can reliably store that information for later reference is the commit message. In general, it is a poor idea to use one-liners as commit messages. A much better idea is described here, in particular the part that recommends to ensure that the commit message covers these four axes:
| What you’re doing | Why you’re doing it | |
|---|---|---|
| High-level (strategic) | Intent (what does this accomplish?) | Context (why does the code do what it does now?) |
| Low-level (tactical) | Implementation (what did you do to accomplish your goal?) | Justification (why is this change being made?) |
There was a problem hiding this comment.
I understand, will refer to the article.
Thank You. :)
| <div class="version-badge"> | ||
| Latest version: {{ site.Params.latest_version }} | ||
| (<a href="https://github.com/git/git/blob/HEAD/Documentation/RelNotes/{{ site.Params.latest_version }}.adoc">Release Notes</a>) | ||
| (<a href="https://gitlab.com/git-scm/git/-/blob/v2.52.0/Documentation/RelNotes/{{ site.Params.latest_version }}.adoc">Release Notes</a>) |
There was a problem hiding this comment.
Here, too, the hard-coded v2.52.0 revision would come back to bite you, if merged unchanged.
The natural fix would be to replace it by HEAD.
But a more fundamental question that should immediately come to your mind when you make virtually the same change in two separate places (the href value in install-header.html as well as the latest_relnote_url value in update-git-version.rb): Why is this URL defined in two separate locations? That's redundant.
In this particular instance, the obvious question is: if update-git-version.rb goes out of its way to define a global parameter latest_relnote_url in addition to latest_version, why on Earth is that latest_relnote_url parameter not used here?
Paying attention to such details and acting on them while you develop patches will automatically improve the quality of your work by ten times, I am sure.
There was a problem hiding this comment.
I will change it to HEAD. Yes, it did come to my mind that why same value I've to change in three places but didn't go much deeper to understand it in full context.
In this particular instance, the obvious question is: if update-git-version.rb goes out of its way to define a global parameter latest_relnote_url in addition to latest_version, why on Earth is that latest_relnote_url parameter not used here?
As for this, ideally, it should be that latest_relnote_url should be used instead of hardcoding it again, but it could be that latest_relnote_url was added later on and was not changed in all places where we mention the link?
The install-header shortcode was constructing the release notes URL manually using latest_version, even though update-git-version.rb already computes a latest_relnote_url parameter for this exact purpose.
Updating the shortcode to use site.Params.latest_relnote_url will remove the duplicated logic, and keeps the URL definition in a single place, hopefully ensures consistency with future changes to the link format.
Should i go ahead and make the change in install-header.html of using the URL from update-git-version.rb, so we have a single source of truth? So basically, the following line -
(<a href="{{ site.Params.latest_relnote_url }}">Release Notes</a>)
2 participants
Changes
Files Changed
hugo.ymlscript/update-git-version.rblayouts/shortcodes/install-header.htmlExample before:
https://github.com/git/git/raw/HEAD/Documentation/RelNotes/2.52.0.adoc
Example after:
https://gitlab.com/git-scm/git/-/blob/v2.52.0/Documentation/RelNotes/2.52.0.adoc
Context
The existing release notes URLs reference the raw AsciiDoc files on raw.githubusercontent.com, which renders as plain text without formatting. As a result, the release notes are harder to read.
This update replaces those raw URLs with links to the rendered AsciiDoc view on the GitLab mirror, making the release notes more readable and user-friendly. The links now reference the tagged version (v2.52.0) to ensure they remain stable and accurately reflect the contents of the 2.52.0 release.