Rails 3.1.2.rc2 just got released. Around the time of the 3.1.1 release, there was also a relatively evolved release process including announcements and release candidates.
Why?
Minor releases (e.g. 2.x) and major releases (e.g. Rails 2 and Rails 3) usually add tons of features and, even in minor releases, often include major refactoring of some parts to improve performance and reduce code complexity. Both features and major refactoring can introduce new bugs, so release candidates are offered to users so they can help with development by testing their applications on the upcoming version.
But point releases (e.g. 3.1.x) don’t add features or change too much code, they just try to have bugfixes. Bugs are fixed by adding a failing test and making it pass, while ensuring the rest of the test suite passes too. This means each point release has less bugs than the previous one. Upgrading to the newest bugfix release is quick, safe, and should be done as often as possible.
In other words, bugfix releases are cheap. Why waste time with release candidates when we can just get 3.1.2 right away? Then, every fix that would otherwise be made between 3.1.2.rc2-3.1.2 can just be released as 3.1.3.
Agree. I was going to say this a while ago as well. It doesn’t matter if we are going to have Rails 3.1.100, it matters for us to release early and release often to make sure those fixes are in people’s hand.
And by the way, after I talked to a lot of non-core guys, they usually don’t care about testing the RC. The only time they would start trying and see the bug would be the released version.
I believe the reason for Release Candidate is not just to test rails, but other components as well, take this RC for example, it depends on un-released version of sass-rails, and a new version of Sprockets even if Rails did not introduce any regressions that doesn’t mean that other components are as safe. The core team simply cannot guarantee that it is working as expected in any environment and for all applications.
Again, that is irrelevant. It is a patch release, noting should be breaking. If something break:
We’re doing it wrong. That mean some change should not be in the patch release.
I doubt people will notice it at the time of RC. again, no one uses RC on production, let alone development unless you’re close to the core team. So the bug report on those plugins won’t come on until the final release. I always seeing this, so I know that’s how it works.
I think we should stop making a big deal of patch release, doing RC only for the minor and major release, and all the patches/fixes would be delivered and tested by user faster.
I have seen previous tiny version releases break the SQL Server adapter. Which to me points out two things, the scope and size of the rails stack and the nasty hacks I have had to do to pass the ActiveRecord test suite.
In general I agree that tiny version releases should not need release candidate gems. On the flip side, I appreciate that core is making an effort to warn upfront too and I think the RC process has value. In my case, it is easy to automate my tests on that git tag or a bundled download.
Versioning software can be a bureaucratic nightmare. It
can also be a swamp in which no-one knows exactly what it
means. To avoid the latter without advocating the former
I think it is reasonable to have some idea of what the
core team presently hold as sufficient cause to change
each of the Major, the Minor and the Patch numbers for
RoR. Is there a guide to this criteria somewhere?
Rails 3.1.2.rc2 just got released. Around the time of the 3.1.1 release, there was also a relatively evolved release process including announcements and release candidates.
Why?
Standardizing the process makes it easier to manage frequent releases.
Pushing a candidate is part of making that process robust and repeatable.
In other words, bugfix releases are cheap. Why waste time with release candidates when we can just get 3.1.2 right away? Then, every fix that would otherwise be made between 3.1.2.rc2-3.1.2 can just be released as 3.1.3.
The candidates are to avoid release screwups, not to capture every last possible bug. (3.1.2.rc1, for example.)
I love the spirit behind doing point releases like crazy and recovering quickly from issues with new point releases. But our experience shows that actually leads to less frequent releases.
the Rails core team used to not release pre or beta versions of minor releases.
But then there was Rails 2.3.6, months after 2.3.5, which totally broke everything. Rails 2.3.7 was quickly released but was also buggy, then 2.3.8 : a total of 3 minor versions in two days. After that event, the Rails core team decided to prerelease even minor versions.
RC releases are very important. If you don’t want to use them (don’t care about them), fine. I found few bugs in RC versions and used veto to reschedule their release. All of that with simply changing my Gemfile and running rake test.
Pushing a candidate is part of making that process robust and repeatable.
It’s bizarre that pushing more releases makes the act of pushing releases easier.
The candidates are to avoid release screwups, not to capture every last possible bug. (3.1.2.rc1, for example.)
I can understand why the core team tries to avoid the scenario that once led to releasing 2.3.6 + 2.3.7 + 2.3.8 in the same day. That day, developers didn’t feel to confident about those releases because first two were “screwups”. But maybe there are ways to improve the release process and detect “screwups” early before pushing the actual gems out. That would eliminate the need for throwaway version numbers (i.e. RCs for patch releases). I don’t have concrete suggestions about this due to my lack of experience for releasing software at this scale.
@everyone: This discussion is not about should Rails follow SemVer for their versioning policy. But Rails patch releases already conform to SemVer in a way they don’t introduce/change features.
During the 1.x and 2.x series the release process looked something like “Everyone on the core team upgrades their application, looks good, ship it”. By 2.3 that was no longer feasible and, as you mentioned, we had some severe fuckups. Even during 3.0 we managed to accidentally break the router. The reality is there’s no substitute for pushing a preview release and asking people to test it, despite what the TDD evangelists may tell you
It’s more ceremony and more work for ‘us’, but the result is less breakage for ‘you’ so I think that’s a good balance.
Indeed. Advocating that we go back to what we did before is a big mistake. Releasing actual gems is the best way to make sure that people know about the impending release and have an opportunity to try it out and discover mistakes. In fact, the RC releases we have done have discovered mistakes. I don’t want to build a process around the assumption of no mistakes.
I think the fact that I messed up rc1 is testament to the fact that RCs
are a good idea
But in general, doing releases is a big hassle. Therefore, I would
prefer to encounter this hassle on my own schedule, not in the middle of
the night when I've just messed up a 'real' release and am racing
against the clock to push out a fixed one.
