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.