Release process

rubyonrails-core
1

I'm finding the release process for Rails somewhat confusing. Several announcements were made that 2.3.3 would be released in early June with a critical bug fix [1]. Lighthouse has this version closed off, so given that the official bug tracker has no open issues, there can't be anything technical holding up the release.

As a consumer of Rails, I am just looking for clear information.

1. Should I rely on Lighthouse as the official source of what bugs/ features go into each release and what is left? Or is there a better source of that information?

2. What is the Rails policy on security fixes and releases? Will crucial security problems be held until the next feature release is ready? Is someone else maintaining a security branch?

3. Where on the http://rubyonrails.org/ site can I find release notes? There isn't even a current release number anywhere there I can find (just "2.3 - 15 March 2009" on the home page. Is that 2.3.0 or 2.3.2?).

Thank you for this useful library and any clarification so I can better understand the Rails release process.

Ari Maniatis

[1] Ruby on Rails — Security Problem with authenticate_with_http_digest

2

1. Should I rely on Lighthouse as the official source of what bugs/ features go into each release and what is left? Or is there a better source of that information?

Things in Lighthouse marked for a particular release are considered to be 'targeting' that release. Odds are they'll be fixed, but unless you see people talking in the ticket about this being "important" or "blocking" then they *could* be moved to the next one

2. What is the Rails policy on security fixes and releases? Will crucial security problems be held until the next feature release is ready? Is someone else maintaining a security branch?

The policy is laid out on rubyonrails.org/security, under normal circumstances we would push a gem release simultaneously with the announcement to the security list.

Without re-litigating the handling of the http-digest vulnerability, it ended up being disclosed publicly before we had had a chance to start working with vendor-sec to coordinate a response. The ideal situation in that case would have been the release of 2.3.3 containing the work arounds for the BigDecimal problem, and the fix for the HTTP-Digest problem. However as we were scrambling to get an announcement out, and 2-3-stable wasn't in a state to be ready for a release, we couldn't get the gems out.

This is not to make an excuse or attempt to justify the situation at present, merely to try to explain how we got here.

2.3.3 is ready to go barring one last potential JSON issue:

http://groups.google.com/group/rubyonrails-core/browse_thread/thread/59bc5464b66f0e7b

Once we have a clear view of that situation, we'll push the gems.

3. Where on the http://rubyonrails.org/ site can I find release notes? There isn't even a current release number anywhere there I can find (just "2.3 - 15 March 2009" on the home page. Is that 2.3.0 or 2.3.2?).

That's 2.3.2, and the release notes are on the blog. When I push 2.3.3 I'll be sure to link to the release notes from the download page, good point.

Thank you for this useful library and any clarification so I can better understand the Rails release process.

The release process is informal, and at this point a bit dysfunctional. We left 2.3.3 too long before pushing it, which means that there are more things to test, and it's a harder hurdle to cross. For this I'm sorry, and I hope we can do better in the future.

My plan for 2.3.4 is to push it out 6 weeks after 2.3.3, so long as there are changes in the repository no matter how small. Then continue that until 3.0 final ships. Hopefully this will mean we don't find ourselves with a big bunch of changes which need to be carefully fixed.

3

The policy is laid out on rubyonrails.org/security, under normal circumstances we would push a gem release simultaneously with the announcement to the security list.

Without re-litigating the handling of the http-digest vulnerability, it ended up being disclosed publicly before we had had a chance to start working with vendor-sec to coordinate a response. The ideal situation in that case would have been the release of 2.3.3 containing the work arounds for the BigDecimal problem, and the fix for the HTTP-Digest problem. However as we were scrambling to get an announcement out, and 2-3-stable wasn't in a state to be ready for a release, we couldn't get the gems out.

I understand that Rails is still a very young project and hasn't yet had time to work out these policies, but the issue right now isn't about the disclosure of the security hole. I've also read that conversation and like many others think that the poster did everything reasonable before disclosing the problem publicly. However, in a situation like this I'd expect that a new branch would be created from 2.3.2 as of 15 March when it was released, and the security patch applied and 2.3.2.1 released. If the current policy is that security patches have to wait until the next release is stable, then I think that policy should be reviewed.

Even now, I would encourage you to release 2.3.2.1. The json issue you mention could be fixed tomorrow or it could take another fortnight depending on the availability of the volunteers who maintain this project.

This is not to make an excuse or attempt to justify the situation at present, merely to try to explain how we got here.

2.3.3 is ready to go barring one last potential JSON issue:

http://groups.google.com/group/rubyonrails-core/browse_thread/thread/…

Which takes us back to the Lighthouse question I asked. I can't find this bug against 2.3.3, so I guess the answer is that Lighthouse is not the definitive place to look for release notes, a list of what was fixed in each version or what remains for that version. It is a little hard for users like me to find the time to follow this list in detail to understand what goes into each release and what is left to do.

I find Lighthouse a bit limiting: it would be nice to see release notes directly there a bit like another project I'm involved in [1].

Once we have a clear view of that situation, we'll push the gems.

> 3. Where on thehttp://rubyonrails.org/site can I find release notes? > There isn't even a current release number anywhere there I can find > (just "2.3 - 15 March 2009" on the home page. Is that 2.3.0 or > 2.3.2?).

That's 2.3.2, and the release notes are on the blog. When I push 2.3.3 I'll be sure to link to the release notes from the download page, good point.

That would be very useful. I've been unable to find release notes anywhere. I'd encourage you to link them from the front page of the site and also have the current version number on the front page of the site (I also cannot find anywhere on the site that mentioned 2.3.2 as the current release.)

I hope you consider some of the above ideas as constructive rather than just critical, from someone who spends 95% of their time in the Java world where many projects have had time to develop clear processes.

Regards Ari Maniatis

[1] https://issues.apache.org/jira/browse/CAY?report=com.atlassian.jira.plugin.system.project:changelog-panel

4

I understand that Rails is still a very young project and hasn't yet had time to work out these policies, but the issue right now isn't about the disclosure of the security hole. I've also read that conversation and like many others think that the poster did everything reasonable before disclosing the problem publicly. However, in a situation like this I'd expect that a new branch would be created from 2.3.2 as of 15 March when it was released, and the security patch applied and 2.3.2.1 released. If the current policy is that security patches have to wait until the next release is stable, then I think that policy should be reviewed.

I have no interest in re-litigating all those issues however if you'd read the policy you'd see that we will, and have historically, pushed releases simultaneously with disclosure.

For this particular case there have actually been 3 subsequent reports which have been investigated and turned out to not be issues with rails or issues at all. Each of those have pushed the release 'just one more week'.

From the outside this is 5ish weeks of no progress, and people are understandably annoyed.

If we find ourselves in this position again with a security release that needs urgent attention and a non-ready stable branch, I think your idea of a 2.3.2.1 is a good one. We'll do that.

Even now, I would encourage you to release 2.3.2.1. The json issue you mention could be fixed tomorrow or it could take another fortnight depending on the availability of the volunteers who maintain this project.

This has been resolved as a non-issue and david will push the gems 'shortly'. How shortly is another question, and this is a single-point-of-failure in our release process which we'll have to resolve before 2.3.4.

Which takes us back to the Lighthouse question I asked. I can't find this bug against 2.3.3, so I guess the answer is that Lighthouse is not the definitive place to look for release notes, a list of what was fixed in each version or what remains for that version. It is a little hard for users like me to find the time to follow this list in detail to understand what goes into each release and what is left to do.

I agree, 2.3.3 is a mess but this mess will be over shortly. I should've reopened the json bug and set its milestone for 2.3.3. We've done that in the past and will do it in the future.

For 2.3.4 if it's in the milestone list, it's intended to be fixed for that release. Bugs can and will move in and out of that milestone, and if you have something you want to block that milestone, you should raise it on this mailing list

I find Lighthouse a bit limiting: it would be nice to see release notes directly there a bit like another project I'm involved in [1].

I'm also finding lighthouse's limitations quite frustrating. It'd probably be a good idea to figure out a list of 'missing features' so we can either ask rick and co to fix them, or migrate somewhere else. Release-notes generation being a big one.

I hope you consider some of the above ideas as constructive rather than just critical, from someone who spends 95% of their time in the Java world where many projects have had time to develop clear processes.

I appreciate the feedback always, especially when it comes with productive actions to take :).

This is a volunteer project which means some things will get messed up. It's not deliberate and we're trying to learn, the best way to help is to provide constructive advice like you've done here.

All the best