Release process

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] http://weblog.rubyonrails.org/2009/6/3/security-problem-with-authenticate_with_http_digest

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.

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

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