On Jun 14, 2008, at 1:24 PM, Rajdeep Dua wrote:
1. Check in by developer in one language doesn't break something
for the
other language., this is especially important as there are some
common files
shared between PHP and Java version
2. Make sure that the unit tests are run for both the versions are
run
before a check-in is made
First of all when ever a patch is to be applied that is known to
affect one or the other language, there is coordination between the
developers to make sure it doesn't break things. In my recollection
this has only occurred twice though, and in general since the nature
of the 2 versions is so closely related (and we're both implementing
the same spec) this doesn't and won't happen a lot.
That doesn't exclude the accidental mishaps though where there was a
hidden bug in one of the 2 languages, take the broken container.js
configuration parser on the php side as an example .. it's a bit
kludgy since the json parser in php is much more sensitive then the
java one, so when a http://uri resource comes along for the first
time, poof it crashes because it thought it was a comment that was
meant to be stripped. In such situations, there's enough people using
the svn repo directly that this will get noticed and fixed a very
short time after it occurring.
Keep in mind that there is a fine balance between development
efficiency & easily allowing people to make contributions, and rules
about how to proceed with contributions. I think that requiring all
java developers to have and maintain a full PHP deployment on their
development systems would prevent a good few of our top java coders
from being able to work on shindig, and visa versa for the php guys.
It would require something unrelated to their skill set to be able to
contribute, and that's something i think non of us wants.
In a sense it's the nature of working out of an open source svn repo..
if it breaks you get to keep both pieces :-)
The version in SVN is usually production ready unless otherwise
announced. Keep in mind that both versions touch a -lot- of end users,
> 200 mil for the java versions and soon > 100 mil for the php
version ... so believe me when i say we all want to keep things
running smoothly and if mistakes do happen they are addressed quite
quickly.
3. Have stable source code tree tagged and documented for reducing
developers efforts in trying to build and run an unstable version.
Our current intention is to have an release when we completed 0.8
specification support and we feel it's ready to be blessed as a real
'release'. Thats what we are collectively currently working towards.
However things aren't often 'unstable' though as mentioned above, so
even working from svn is quite doable at the moment. Most containers
take a snapshot of svn when they feel it satisfies their needs and
work from that . (tools like Piston: http://piston.rubyforge.org/ can
help with that btw)
-- Chris
