Erector - Developers

Want to help develop Erector? Here's what to do.

Check out project from rubyforge:

svn co svn+ssh://developername@rubyforge.org/var/svn/erector/trunk erector

Install gems:

sudo gem install rake rails rspec rubyforge hpricot treetop

Run specs:

rake

Check out the available rake tasks:

rake -T

Sign up for the erector-devel mailing list:

erector-devel mailing list

Join the Lighthouse project:

mailto:erector-devel@rubyforge.org with your Lighthouse account name, then visit http://erector.lighthouseapp.com

Versioning and Release Policy

• Versions are of the form major.minor.tiny
• Tiny revisions fix bugs or documentation
• Tiny revisions are roughly equal to the svn revision number when they were made
• Minor revisions add API calls, or change behavior
• Minor revisions may also remove API calls, but these must be clearly announced in History.txt, with instructions on how to migrate
• Major revisions are about marketing more than technical needs. We will stay in major version 0 until we're happy taking the "alpha" label off it. And if we ever do a major overhaul of the API, especially one that breaks backwards compatibility, we will probably want to increment the major version.
• We will not be shy about incrementing version numbers -- if we end up going to version 0.943.67454 then so be it.
• Developers should attempt to add lines in History.txt to reflect their checkins. These should reflect feature-level changes, not just one line per checkin. The top section of History.txt is used as the Release Notes by the "rake publish" task and will appear on the RubyForge file page.

How to push a release

1. Pick a version number. For the build number run 'svn info | grep Revision'
2. Look at History.txt and make sure the release notes are up to date. Put the version number on the top line (after the "==").
3. Put the version number in erector.rb as Erector::VERSION.
4. Check in with a comment, e.g. 'svn ci -m "release 1.2.3"'
5. Run 'rm -rf spec/rails_root' so that you don't include 3 versions of rails in the erector gem (TODO: there must be a better way to exclude these from the gem)
6. Run 'rake package' so that you can see whether the gem generation seems to work locally before proceeding to try to upload it to rubyforge (if you skip this step, the package will be generated when you run rake release)
7. If you haven't done so before, run 'rubyforge setup' and 'rubyforge config' (for more details on these steps, see README.txt in the rubyforge gem
8. Run 'rake release VERSION=1.2.3'. (The parameter is to confirm you're releasing the version you intend to.)
9. Run 'rake publish_docs web publish_web' cause the docs and site need to be updated, at least with the new version number.
10. Immediately go into History.txt and make a new section at the top. Since we won't yet know what the next version will be called, the new section will be noted by a single "==" at the top of the file.
11. Send email to erector-devel mailing list announcing the new release.