This bug made it so sometimes (in my case all the time, no idea why), exception would not be logged to console, and the error page would be a generic “Things went bad” page with no information.
https://github.com/rails/rails/pull/36532
The bug was was fixed on July 15, 2019. That’s before even the 6.0.0.rc2. Somehow, it passed through hoops and didn’t get released right away.
It seems someone realized that on December 21, 2019 and backported the fix so that it would be in the next 6.0.X.
Sadly, that was 9 days after 6.0.2 was released, and it took almost 5 more months before another release came around… (A release which was yesterday. I wonder if you planned May of WTFs to be after a release)
I just think that maybe bugfix releases could be done more often, and maybe there is a way to improve processes so bugfixes are less likely to be forgotten on master?
3 Likes
In theory we release every month, but I admit I’m being neglecting it this time. I’m usually the release manager and I make sure bug fixes are being backported and releases are happening often. Other member of the core team help with those tasks as well but it is ultimately my self-imposed responsibility.
While I can’t guarantee it will not happen again I can promise I’ll setup a schedule for releases that will be public so people can hold us accountable if we drop the ball again.
5 Likes
Not to rub it in, I appreciate all the time you and others put in the project, but:
The only way the release could be close to being monthly, is if you include the security releases (those with a 4th number, not sure how you call them).
Without the security patches, since 5.2.0 which was in april 2018, there were 9 releases. Thats almost 3 months per release.
As for missing bugs, nobody is perfect 
but I notice that there is no tag for “bug” in github. I wonder how you even manage to find the bug fixes in all of that.
That is why I said “in theory” 
. There were times where a monthly release didn’t make sense since we had only very few commits. But it was after Rails 5.2 that I stoped to release monthly, for many reasons. I still think monthly schedule is what we should aim. I’ll make sure that happen.
I read all the commits that happen in the repository, every day. You get used to differentiate a bug fix from a new feature after 10 years doing that.
7 Likes
How is the next release planned? Are all the issues for next release added to the proper milestone? How often does this happen.
For example I cannot upgrade my rails project to use master, because of this bug: has_many :through no longer works with UUID primary keys or custom type PKs · Issue #38340 · rails/rails · GitHub and I am wondering if this will be fixed before next release. And it seems it introduced unexpected breaking change. It issue has no assigned milestone. So it would suck, if Rails were released without fixing this one.
Thank you Rafael for taking care of the releases 
I’m wondering, what do you think about having a fixed day of the month that it’s announced publicly and then follow that? Everything that is merged will be released, if not you know that you have one more month to get it ready for the next release.
At the top of my mind I’m thinking about Gitlab having a fixed day for releases, or open sources projects like KDE having one as well. For example you know that a new version of Frameworks is tagged the first week of the month and released the week after:
tagging happens the first Saturday of every month, and the public release is one week later.
I don’t know if this would increase the pressure / work for doing this, it’s just a random thought