-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Version 0.24.1 #5358
Version 0.24.1 #5358
Conversation
CHANGELOG.md
Outdated
- Formatter: fix formatting `$1?`. ([#5313]) | ||
- Formatter: ensure to insert a space between `{` and `%` characters to avoid forming `{%` macros. ([#5278]) | ||
|
||
## Documentation fixes |
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.
standardize "fixed" vs "fixes" (I prefer "fixes" everywhere)
CHANGELOG.md
Outdated
# 0.24.1 (TBA) | ||
|
||
## New features | ||
- Add ThinLTO support for faster release builds in LLVM 4.0 and above. ([#4367]) |
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 is no need for square brackets around #4367 etc.
Pushed fixed to fix the links, and to add a thanks to each author. |
I assume this is supposed to be the place to discuss the new changelog format? A) Thank you, I really like that the contributers are mentioned. That's a nice and appreciates the work. I was thinking about suggesting something like that =) But I don't think it's necessary for minor edits (say fixing a typo in the documentation). They are unmistakenly none the less important contributionss to the project, but I don't think it's worth listing individual changes in too much detail if it's just a lot of noise with little to no useful information. B) I am not sure if the entries are sorted by anything (are they?) But I think at least the breaking changes should be on top of the list. |
@straight-shoota they're sorted by category, then my opinion of their importance, basically. There's only one breaking change this release, and it's within the first 5 items and has a giant bold (breaking-change) so I didn't put it right at the top. |
And regarding format, ideally I'd love to write more than one line for some changes, but I think that's going too far in the realm of a blog post. The less-important changes are all far down the bottom - just stop reading when you get bored. And I like it being an exhaustive list. I don't think it's an issue. What do people think? |
IMHO: Breaking changes should be distinct, and at the top, they're the most important information. There are too many entries listed; it's hard to skim through. Some entries could easily be grouped, e.g.: The "doc fixes" and "misc" sections are mostly noise. Removing them would have no impact on the changelog itself. A simple link to the milestone bugtrack (as per the previous changelog entries) for an exhaustive list of bug fixes would be more efficient (exhaustive, can be filtered, ...). |
Good stuff @RX14 @straight-shoota, w.r.t. typo PRs, people should be recognized no matter what they did. The reader of the CHANGELOG is clever to think the complexity that was involved. When in doubt, add a name more than one less. To me, it also boils down to respect of the mere contribution. Though I somewhat agree with @ysbaddaden in that small non-logic changes, like typo fixes, could be grouped like
(^ Only using backticks to avoid paging random people on Github for sake of example)
Absolutely agree. |
@RX14 The changelog does not just consist of the current section but it compiles to a long document with thousands of entries. So you can't just "stop reading" when your scanning through the entire file. I think it would be very helpful to have this list as consise and significant as possible. For example, these lines
Could become:
It contains all the information except the exact location of the fix (which is insignificant) but is much more condensed. This is similarly true for the Misc section. Only #5217 should be noted specifically because it contains a significant change which could break existing tool integrations using |
I actually disagree that breaking changes should be in their own section. They should be very obvious but I think (breaking-change) is more than enough as long as they're near the top. I'm fine condensing some related changes into single lines but I think this changelog should be exhaustive. It should link to every PR merged in the time period. @straight-shoota I don't understand why you want the changelog to be small. If you want to only give the important changes in the release, we can make a blog post describing the new 0.24.1 and 0.24.0 releases in much more detail and with much more editorial discretion. |
I agree on linking to every PR and it is probably fine to have breaking changes standing out but not necessarily on the very top. If the changes are sorted by importance, this should be okay and breaking changes will naturally be relatively high. 👍 I want to avoid unnecessary clutter and I think it is completely irrelevant in which type's documentation there is a typo fix that adds a missing 'r'. |
I've changed my mind. You really don't save much space by removing these lines. Why not keep it simple: 1 commit = 1 line? People's contributions are not "clutter", no matter how small. |
The primary purpose of a changelog is documenting the development of the software, not keeping track of individual contributions. Each entry should describe a specific logical change to the codebase. "Fixing typos in documentation" should be considered as one logical change. From the perspective of a changelog, it doesn't matter if it happened in multiple commits. |
@straight-shoota I agree, one commit = one line was a bad way to describe it: one change = one line is much better. However I argue that the documentation fixes are separate changes. It's bikeshedding either way, and the impact of any decision will be minimal at best. So I'll collapse the documentation changes. I don't think the formatter or doc tool changes should be collapsed though, since each change can have an impact on people's codebase by itself. |
dfab05d
to
c875fb6
Compare
I condensed code refactors and doc fixes into single lines, and added some new commits merged since I made this PR. |
I would really love to release this before the end of the week and get 0.24.1 out before christmas. The current state of 0.24.0 is half-release, half-prerelease and everyone is confused. We need to release 0.24.1 and get everyone on the same version of crystal again. Plus we have the LLVM version upgraded so that we can use |
I'm using 0.24.1 for a month +/- now, no major issues were found, tested with multiple big community shards. You got an OK from me. |
@mverzilli any word on the binary builds of the new release? Any help that can we provide? Thank you. |
Hi @luislavena! We're working on it. The plan is to start using this at least for linux x64 packages: https://github.com/crystal-lang/distribution-scripts However, those scripts depend on @ysbaddaden's Alpine package, so we want to be sure that we can reproduce the whole release process with this new approach. That's where we are at. As soon as we manage to generate packages in a way that we feel confident we can repeat for 0.25, we'll release. Our current ETA is in a few days, maybe one week (original goal was before the end of this week, we're striving to make it might slip to next week). |
Very excited to see the new efforts for transparency! Can I ask why 0.24.1 has two different tags? |
Because we want to switch to |
In an effort to bring more transparency and less guesswork to the release process, we are trialling creating "release PRs", which track the release of new versions of Crystal. These PRs contain the changelog diff, but actually serve as a more general tracking issue for the release. As soon as this PR is merged,
master
will be tagged as the0.24.1
and a full "release" with blog post and binaries will be done ASAP.I've also come up with a new, slightly more structured, changelog format which is worth discussion.