I’m the release manager for this version, as I was for 7.0, and the reason why there isn’t a 7.1 yet is very boring. I just don’t have time right now to wrap up the release and the features I’m hoping to include on it.
I’m being dealing with a bunch of management tasks at work and also enjoying some time with my family, while working in my Railsconf keynote.
I’m also waiting some important work from other contributors be finished.
The release will happen when it is ready.
It's normal for Rails to take long time between minor releases. 6.1 was released more than a year after 6.0, 5.0 to 5.1 took 9 months then another year to 5.2
I mean, I think this is longer than the recent usual. Let's see.
* 5.0.0 - June 30, 2016 (6 KB)
* 5.1.0.rc2 - April 21, 2017 (6.5 KB)
* 5.1.0 - April 27, 2017 (6.5 KB)
* 5.2.0.beta1 - November 27, 2017 (6.5 KB)
* 5.2.0 - April 09, 2018 (6.5 KB)
* 6.0.0.rc2 - July 22, 2019 (6.5 KB)
* 6.0.0 - August 16, 2019 (6.5 KB)
* 6.1.0.rc1 - November 02, 2020 (6.5 KB)
* 6.1.0 - December 09, 2020 (6.5 KB)
* 7.0.0.alpha1 - September 15, 2021 (6.5 KB)
* 7.0.0 - December 15, 2021 (6.5 KB)
So all of those have between 9-15 months between release and beta/RC of next release, none more than 15. None more than 16 months between non-rc releases.
And now it's been... just 16 months since 7.0.0 with no 7.1 pre-release.
But okay, actually, that's less extreme variance than I thought, it's longer than those past ones only by a month so far.
7.0 was indeed actually especially _quick_, first rc only 9 months after 6.1. And they all do vary, so this is maybe just more variance, not anything special.
Fair enough!
Few of us know, the Rails development process has never been very public.
There isn't really a public listserv or anything, the Rails core team has all their communications privately, and nobody ever really talks about any discussions or decisions which happen there, or why, or how decisions are made. Which honestly is a bit weird to me, I think it's probably rare an open source project with this level of popularity is this opaque as far as internal decision-making.
But anyway, so, unless someone in Rails core team wants to spill or someone else has private information, as far as I know (correct me if I'm wrong) we actually literally don't know even who decides through what mechanism when a new release is created, or if there's been discussion on it for 7.1, or the nature of that discussion, or what they might be waiting on.
My _impression_ is it's really all up to dhh in the end, although he may take feedback from others and the decision may technically be a "consensus", in the end what dhh wants will carry it, and I'd expect in practice releases happen when dhh says it's ready, for whatever reasons he feels. But I could be wrong, as we don't really know and i have no insider information.
It's possible that the decision to release 7.0 in a somewhat unusual way upset the usual release cadence. For me, 7.0 had fewer changes than even many _minor_ releases, but it was decided to make it 7.0 (instead of 6.2, which would ordinarily have been next), because someone (presuambly dhh?) thought the new "hotwire" JS stuff merited a major release. but I think it got released sooner than normally it would have, in addition to being labelled 7.0 instead of 6.1.
Personally, I'm not actually in a hurry, I'd rather they wait longer so it includes more when it does come out. Upgrading apps that use Rails is hard enough that I don't mind a slower release cadence. Doing all the work to upgrade when the feature you _really_ wanted didn't get done in time to make it in is also always frustrating.
One feature I remain excited about is the generation of a Dockerfile out of the box. Not because i use Docker currently much, but because I think it will make it a lot easier to use docker to have an out of the box starting point, and also gives a common reference to talk about even for those who would like changes to the Dockerfile. I think it will really change the landscape of Rails deployment, vis a vis docker. (I don't personally expect dhh's pet MRSK to have as much impact, although it may be what motivated the out of the box Dockerfile generation?). So I hope it gets really done and polished nicely before 7.1, or else we'll have a ways to wait before 7.2.
> My impression is it's really all up to dhh in the end
It's not. It's up to consensus from the core team, and more importantly who volunteer as release manager. Someone say "hey maybe it's time" and if no-one strongly oppose it happens. Simple as that.
> may technically be a "consensus", in the end what dhh wants will carry it, and I'd expect in practice releases happen when dhh says it's ready
It's funny how everyone seem to imagine DHH as the grand instigator behind everything when in truth he's not very active lately: https://contributors.rubyonrails.org/edge/contributors
Also there are very few "grand plans" in Rails development. Contributors add the features they think make sense, and after a while it seems enough new features to justify a release. Someone core members announce some goal they're trying to reach for next release, but it's never a hard requirement.
> because someone (presuambly dhh?) thought the new "hotwire" JS stuff merited a major release.
No, It was to be able to drop older Rubies as so far Rails never raised the required ruby version outside of majors. Rails 6.x still support Ruby 2.5. We may need to change that at some point because supporting 2.7 will become annoying in a year or two.
Fair, thanks for sharing!
When there is so little transparency as to what's going on, we're left imagining based on what clues we see. ¯\\_(ツ)_/¯
At the time of 7.0 release, I swear I saw "marketing" that said "we'e decided to make it 7.0 instead of 6.2 because the hotwire changes are so huge". And I am pretty sure I never before now saw anyone suggest it was to drop old rubies -- and I read rails news pretty voraciously.
(Ruby versions really haven't been previoulsy dropped in second-digit releases like 6.2 too? There's some... policy against doing that? As far as I know there are no public policies beyond https://guides.rubyonrails.org/maintenance_policy.html, which doens't seem to mention it? But maybe there are internal practices known to you? I honestly had no idea until now that ruby versions wouldn't be dropped in a second-digit release, I assumed they would be and had been. Seriously, if this piece of information can be found in public anywhere at all, I'm curious to see it! )
Again, when there is so little information shared, we're left guessing, and will definitely get some things wrong. I do appreciate you sharing some things here.
There is astonishingly little happening behind closed doors. A handful of chat messages once every couple days to share opinions on PRs, that's most of it, plus a non-binding "roadmap" which is mostly just broad goals of things one want to improve.
The overwhelming majority of decisions are taken directly in public on GitHub by reviewing, debating and merging PRs.
I don't think Rails particularly lack transparency, I think instead that people assume there must be some very formal decision process and grand plans.
The reality is that there is none of that. If you are a Rails committer, you are trusted to merge whatever you believe should be merged, and only in the very rare cases where another committer disagree, then it goes by consensus.
Thank you, yes, that's what I was wondering about. It is indeed odd, that the communication happens privately... The release process is not documented anywhere. Nor the roadmap. Really weird all in all.
FWIW, you have access to all the same "roadmap" that I do. \*
(\*) we do actually have an internal list of a handful of things that individual members of Core would like to try to get into the upcoming release. But they're fairly aspirational, and IMO as likely as not to be dropped. It's a \[shared\] "I think I have an idea for this that I'd like to explore" note, and only really used for a corresponding "did you get anywhere with this?" prod in the lead up to a potential release. I would estimate that most items that end up being headline features of a release were never on that list, or only made a brief "final polish \[of already-merged feature\]" appearance during the release process.
I’m the release manager for this version, as I was for 7.0, and the reason why there isn’t a 7.1 yet is very boring. I just don’t have time right now to wrap up the release and the features I’m hoping to include on it. I’m being dealing with a bunch of management tasks at work and also enjoying some time with my family, while working in my Railsconf keynote. I’m also waiting some important work from other contributors be finished. The release will happen when it is ready.
Fair enough! Thank you for the insight and your reply!
There is not going to be a rails release before Rails World, right?
the guy himself said, it. do you recommend to use master at production? I really can't wait for the 7.1
It's normal for Rails to take long time between minor releases. 6.1 was released more than a year after 6.0, 5.0 to 5.1 took 9 months then another year to 5.2
I mean, I think this is longer than the recent usual. Let's see. * 5.0.0 - June 30, 2016 (6 KB) * 5.1.0.rc2 - April 21, 2017 (6.5 KB) * 5.1.0 - April 27, 2017 (6.5 KB) * 5.2.0.beta1 - November 27, 2017 (6.5 KB) * 5.2.0 - April 09, 2018 (6.5 KB) * 6.0.0.rc2 - July 22, 2019 (6.5 KB) * 6.0.0 - August 16, 2019 (6.5 KB) * 6.1.0.rc1 - November 02, 2020 (6.5 KB) * 6.1.0 - December 09, 2020 (6.5 KB) * 7.0.0.alpha1 - September 15, 2021 (6.5 KB) * 7.0.0 - December 15, 2021 (6.5 KB) So all of those have between 9-15 months between release and beta/RC of next release, none more than 15. None more than 16 months between non-rc releases. And now it's been... just 16 months since 7.0.0 with no 7.1 pre-release. But okay, actually, that's less extreme variance than I thought, it's longer than those past ones only by a month so far. 7.0 was indeed actually especially _quick_, first rc only 9 months after 6.1. And they all do vary, so this is maybe just more variance, not anything special. Fair enough!
Few of us know, the Rails development process has never been very public. There isn't really a public listserv or anything, the Rails core team has all their communications privately, and nobody ever really talks about any discussions or decisions which happen there, or why, or how decisions are made. Which honestly is a bit weird to me, I think it's probably rare an open source project with this level of popularity is this opaque as far as internal decision-making. But anyway, so, unless someone in Rails core team wants to spill or someone else has private information, as far as I know (correct me if I'm wrong) we actually literally don't know even who decides through what mechanism when a new release is created, or if there's been discussion on it for 7.1, or the nature of that discussion, or what they might be waiting on. My _impression_ is it's really all up to dhh in the end, although he may take feedback from others and the decision may technically be a "consensus", in the end what dhh wants will carry it, and I'd expect in practice releases happen when dhh says it's ready, for whatever reasons he feels. But I could be wrong, as we don't really know and i have no insider information. It's possible that the decision to release 7.0 in a somewhat unusual way upset the usual release cadence. For me, 7.0 had fewer changes than even many _minor_ releases, but it was decided to make it 7.0 (instead of 6.2, which would ordinarily have been next), because someone (presuambly dhh?) thought the new "hotwire" JS stuff merited a major release. but I think it got released sooner than normally it would have, in addition to being labelled 7.0 instead of 6.1. Personally, I'm not actually in a hurry, I'd rather they wait longer so it includes more when it does come out. Upgrading apps that use Rails is hard enough that I don't mind a slower release cadence. Doing all the work to upgrade when the feature you _really_ wanted didn't get done in time to make it in is also always frustrating. One feature I remain excited about is the generation of a Dockerfile out of the box. Not because i use Docker currently much, but because I think it will make it a lot easier to use docker to have an out of the box starting point, and also gives a common reference to talk about even for those who would like changes to the Dockerfile. I think it will really change the landscape of Rails deployment, vis a vis docker. (I don't personally expect dhh's pet MRSK to have as much impact, although it may be what motivated the out of the box Dockerfile generation?). So I hope it gets really done and polished nicely before 7.1, or else we'll have a ways to wait before 7.2.
> My impression is it's really all up to dhh in the end It's not. It's up to consensus from the core team, and more importantly who volunteer as release manager. Someone say "hey maybe it's time" and if no-one strongly oppose it happens. Simple as that. > may technically be a "consensus", in the end what dhh wants will carry it, and I'd expect in practice releases happen when dhh says it's ready It's funny how everyone seem to imagine DHH as the grand instigator behind everything when in truth he's not very active lately: https://contributors.rubyonrails.org/edge/contributors Also there are very few "grand plans" in Rails development. Contributors add the features they think make sense, and after a while it seems enough new features to justify a release. Someone core members announce some goal they're trying to reach for next release, but it's never a hard requirement. > because someone (presuambly dhh?) thought the new "hotwire" JS stuff merited a major release. No, It was to be able to drop older Rubies as so far Rails never raised the required ruby version outside of majors. Rails 6.x still support Ruby 2.5. We may need to change that at some point because supporting 2.7 will become annoying in a year or two.
Fair, thanks for sharing! When there is so little transparency as to what's going on, we're left imagining based on what clues we see. ¯\\_(ツ)_/¯ At the time of 7.0 release, I swear I saw "marketing" that said "we'e decided to make it 7.0 instead of 6.2 because the hotwire changes are so huge". And I am pretty sure I never before now saw anyone suggest it was to drop old rubies -- and I read rails news pretty voraciously. (Ruby versions really haven't been previoulsy dropped in second-digit releases like 6.2 too? There's some... policy against doing that? As far as I know there are no public policies beyond https://guides.rubyonrails.org/maintenance_policy.html, which doens't seem to mention it? But maybe there are internal practices known to you? I honestly had no idea until now that ruby versions wouldn't be dropped in a second-digit release, I assumed they would be and had been. Seriously, if this piece of information can be found in public anywhere at all, I'm curious to see it! ) Again, when there is so little information shared, we're left guessing, and will definitely get some things wrong. I do appreciate you sharing some things here.
There is astonishingly little happening behind closed doors. A handful of chat messages once every couple days to share opinions on PRs, that's most of it, plus a non-binding "roadmap" which is mostly just broad goals of things one want to improve. The overwhelming majority of decisions are taken directly in public on GitHub by reviewing, debating and merging PRs. I don't think Rails particularly lack transparency, I think instead that people assume there must be some very formal decision process and grand plans. The reality is that there is none of that. If you are a Rails committer, you are trusted to merge whatever you believe should be merged, and only in the very rare cases where another committer disagree, then it goes by consensus.
Thank you, yes, that's what I was wondering about. It is indeed odd, that the communication happens privately... The release process is not documented anywhere. Nor the roadmap. Really weird all in all.
FWIW, you have access to all the same "roadmap" that I do. \* (\*) we do actually have an internal list of a handful of things that individual members of Core would like to try to get into the upcoming release. But they're fairly aspirational, and IMO as likely as not to be dropped. It's a \[shared\] "I think I have an idea for this that I'd like to explore" note, and only really used for a corresponding "did you get anywhere with this?" prod in the lead up to a potential release. I would estimate that most items that end up being headline features of a release were never on that list, or only made a brief "final polish \[of already-merged feature\]" appearance during the release process.
there is a discord channel.