On Dec 16, 2008, at 3:11 PM, Matthew Kemp wrote:
We should decide on how to handle that. One option would be to make
an erma-core repo and always have that be the latest official
release. In my opinion it's going to be hard having one developer
only maintain an official copy.
Matt
I'm fine with that approach. Some other teams on github work that way
as well.
So, to outline what the proposed development process is then.
Fixing a bug/implementing a feature
--------------------------------------------------
* Create a ticket in Jira at http://code.orbitz.net
* Fix your bug in a branch and push it to your public repository in
a branch specifically for your bug. The suggested name for that branch
is "fixes/<bug id>". For example, if I was fixing ERMA-42, I would
push my fix to my public repository on Github (http://github.com/dougbarth/erma
) in a branch called "fixes/ERMA-42"
* Update the Jira issue with a link to your branch containing the fix
Reviewing a fix
----------------------
* Pull down the user's branch containing the fix
* Diff the changes, make sure they are correct
* Run the tests
* Generally sign off
* If the changes are good, merge and push them to the shared
repository
Cutting a release
------------------------
* Grab the latest changes in the official repo
* Run the tests
* Generate the binaries, publish them to ???
* Tag the release
* Push the changes to the official repo.
Sound good, minus the obvious missing details like where the binaries
are posted?
--
Doug Barth
_______________________________________________
Mailing list: https://launchpad.net/~erma-core
Post to : erma-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~erma-core
More help : https://help.launchpad.net/ListHelp
