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

Clone Erector from Github or create your own fork:

git clone git://github.com/erector/erector.git
cd erector

Install gems:

bundle install

Run specs:

rake

Check out the available rake tasks:

rake -T

Sign up for the mailing list:

'erector' Google Group

Watch the github repo at

http://github.com/erector/erector

Join the Pivotal Tracker project at

http://www.pivotaltracker.com/projects/482

Basic read-only git usage

First, install git. Then download erector using git:

git clone git://github.com/erector/erector.git

Generate a diff between what you have edited and what you have run git add on:

git diff

Generate a diff between what you have run git add on and locally committed:

git diff --cached

Commit locally (into your .git directory):

git commit -a

You can update from the erector repository at github with:

git pull

However, since you have checked out git read-only, you cannot push back your changes with:

git push

Instead, mail a diff to the mailing list, or fork your own github repository and send a pull request.

Read/write access

The following instructions assume you have been listed as a collaborator on the github pivotal erector project.

First, install git. Then:

git clone git@github.com:pivotal/erector.git

To push your changes back to the main git repository:

git commit -a
git pull
# Deal with merge issues if any.
git push

To get other people's changes:

git pull

Versioning and Release Policy

• Versions are of the form major.minor.tiny
• Tiny revisions fix bugs or documentation
• 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.
• 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. Either increment the major, minor, or tiny version from the previous version.
2. Look at History.txt and make sure the release notes are up to date. Put the version number and today's date on the top line (after the "==").
3. Put the new version number in VERSION.yml (not in erector.gemspec; that'll get changed on its own)
4. Commit these changes, e.g. 'git commit -a'
5. 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)
6. 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)
7. Run 'rake release VERSION=1.2.3'. (The parameter is to confirm you're releasing the version you intend to.)
8. Run 'rake publish' cause the docs and site need to be updated, at least with the new version number.
9. 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.
10. Send email to erector Google Groups mailing list announcing the new release.