Want to help develop Erector? Here's what to do.
Clone Erector from Github or create your own fork:
git clone git://github.com/pivotal/erector.git cd erector
Check out the available rake tasks:
Sign up for the mailing list:'erector' Google Group
and check out the archives of the old erector-devel mailing list
Watch the github repo athttp://github.com/pivotal/erector
Join the Pivotal Tracker project athttp://www.pivotaltracker.com/projects/482
Basic read-only git usage
First, install git. Then download erector using git:
git clone git://github.com/pivotal/erector.git
Generate a diff between what you have edited and what you have run git add on:
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:
However, since you have checked out git read-only, you cannot push back your changes with:
Instead, mail a diff to the mailing list, or fork your own github repository and send a pull request.
The following instructions assume you have been listed as a collaborator on the github pivotal erector project.
First, install git. Then:
git clone firstname.lastname@example.org: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:
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
- Pick a version number. Either increment the major, minor, or tiny version from the previous version.
- 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 "==").
- Put the new version number in
erector.gemspec; that'll get changed on its own)
- Commit these changes, e.g. 'git commit -a'
- 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)
- 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)
- Run 'rake release VERSION=1.2.3'. (The parameter is to confirm you're releasing the version you intend to.)
- Run 'rake publish' cause the docs and site need to be updated, at least with the new version number.
- 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.
- Send email to erector Google Groups mailing list announcing the new release.