Rails release improvements

rubyonrails-core
1

Hi folks,

I want to talk about the release process. Specifically, I want to talk about how we can improve our release process.

There are a couple things I want to see in our release process:

1) Regular, periodic releases.

I had been shooting for every four weeks for the 3.0.x series. I don't think this means we have to be held to a particular deadline. I think that if people know that approximately every N weeks, we'll have a release, it will help reduce upgrade friction.

Mainly what this means to me is setting expectations with the community, and sticking to what we say.

2) Distributed responsibility

I would like to improve our Bus Factor. Today, I am the only one doing releases. That means we have a Bus Factor of one. If I get hit, who will take responsibility?

In order to fix this, I think we need other core team members to do releases. In fact, I think it should be a requirement *as a core team member* to do releases.

We require that core team members are able to work on all aspects of Rails (AR, AS, AP, etc). If we make this requirement for the code base, we need to make this requirement of our process.

We all need to go through the pain of the rubber actually hitting the road. We all need to make the tough decision to release, or to face our users and tell them why it is late.

I propose that we each take turns releasing Rails, and we publish who will be doing which release. I think it will improve our Bus Factor, frequency and stability of our releases, and improve our team overall.

If we can agree on these items, I will put together documentation about how to release Rails, along with a roster of who will be releasing what. I will even personally work with each core team member until we're all comfortable with the process.

The status quo cannot remain. I can't be around all the time to do releases, as frankly, it's burning me out.

2 

+1 all around, a suggestion:
Have a release rotation that cycles through the core team/contributor list,
so everyone is in charge perhaps only once every other month (or a few
weeks). Make sure the last guy to release hounds the next guy (so you, Aaron
would be first at bat to hound who's on deck) to make sure they have their
stuff together and know how to do it properly.
-Nick
3

Aaron,

1) I'm totally agree on that one. Let's stick with this four weeks release cycle for RC cut, and 48 hours for regression report.

2) You've always done a great job for the Ruby on Rails community. From what you said, I think it make a lot of sense to rotate the release responsibility to every core team member. I mean, it should not be *your* responsibility to do the hard work and release the gem every time. And you shouldn't be the only one to take the blame if the release is broken.

It would be totally worth it if you can provide everybody the process of cutting a release. In that case, everybody will have a reference on what to do, and will be able to cut the release, in the perfect quality as you did, in the future.

Thank you for your contribution to Rails community. I think we're all appreciate your contribution. <3 <3 <3

- Prem

4

Just wanted to say thank you Aaron for putting so much of your energy into the rails community. As a developer I know how tiresome the job can be at times and a task as large as the rails gem release should be delegated to more than one person. As a rails developer I can’t thank you enough.

Dave

5

Likewise, Aaron, you have made incredible contributions to this whole process. Increasing the bus-factor and having more folks who are able to handle a release would indeed be great.

On the release timing front, I actually think something longer than four weeks should be the default goal. Artificially limiting to four weeks may make it difficult to get larger scale feature work completed. I also think that more frequent releases won't actually benefit the users and businesses who rely on Rails. Instead, it will only make it more complex to keep in step with changes in the frameworks while ensuring existing apps still run.

Along those lines, 48 hours for regressions is entirely too short. It doesn't do the project any good to aggressively declare GM on a release only to have to spin fast subsequent updates because a major issue was not identified fast enough. I wouldn't want to see any less than a week for regression reports.

-Jury

6

I do agree 48 hours might be a little short timespan for regressions.

7

I agree an excessively aggressive release schedule would, in the end, likely prove detrimental to ROR. I also feel that 48 hours is inadequate to install, test and report on a new release candidate on anything other than a purely superficial level.

On the issue of "lead dog" I leave that to the core team to settle among themselves. I deal with several projects that all take different approaches to that problem and most seem to work well enough that no one of them commends itself above all the rest. Having said that, should my opinion matter then my preference would be for a "team" release system wherein all the "bus" people reach consensus among themselves of when to release a candidate and when to do a general release and no one of them takes the "heat" for delays and regressions.

I appreciate very much all of the work that everyone concerned, past and present, has put into this project.

8

Hi folks,

I want to talk about the release process. Specifically, I want to talk about how we can improve our release process.

There are a couple things I want to see in our release process:

1) Regular, periodic releases.

Deadlines help force the issue of what's in and out of a release, too. +1.

I'm wary of putting too much importance/significance in the fixed schedule itself, rather than the desired outcome: reasonably frequent stable releases that are easy to upgrade to. I doubt this'll become an issue.

2) Distributed responsibility

Happy to step back in front of the bus on these. Releases are a pretty tedious exercise.

Thanks Aaron!

9

> Hi folks, > > I want to talk about the release process. Specifically, I want to talk about > how we can improve our release process. > > There are a couple things I want to see in our release process: > > 1) Regular, periodic releases.

Deadlines help force the issue of what's in and out of a release, too. +1.

I'm wary of putting too much importance/significance in the fixed schedule itself, rather than the desired outcome: reasonably frequent stable releases that are easy to upgrade to. I doubt this'll become an issue.

Agreed. I really don't want hard deadlines so much as I want to set expectations with users. Maybe we can say something like "approximately once per month".

We have to strike a good balance. If we release too frequently, people are annoyed, but upgrades should be easier. If we release too infrequently, releases are harder and upgrades are harder.

I guess it's important to make the distinction between setting expectations with the community vs timeline. I don't think it really matters what the schedule is, as long as everyone knows.

> 2) Distributed responsibility

Happy to step back in front of the bus on these. Releases are a pretty tedious exercise.

Yay! I'll do the next releases (all releases through 3.1.0 and 3.0.10) and document the process along the way. We can start handing releases around after that.