On Jan 30, 2007, at 9:44 AM, kelvin goodson wrote:
Jeremy,
thanks for your reply. A key time when this has become an issue
for me is
when applying patches. My general process has been to ensure I have a
complete clean svn extraction, build it to see if there are any
current
issues in the trunk, inspect and apply the patch and build it
again. If
there are deltas in the error sets (hopefully the initial build's
error set
was empty) then there's an issue with the patch. This has meant in
the past
often even small patches still take an hour or so to apply. Now
that the
trunk has significantly less chance of being stable this has become
unworkable.
Agreed. Sounds like the issue here though is that there is
insufficient test coverage in SDO so check whether or not a patch was
good. If SDO operates on the principle that its build is good
(including running tests as part of that build), then you can take a
working copy, apply the patch, rebuild and have confidence that the
build will remain good. That's very workable.
If something downstream breaks unexpectedly then it indicates that
there is a hole in the test coverage i.e. that downstream code was
doing something not clearly defined in the API contract. This is a
great opportunity to improve the API coverage to clarify this
interaction and either document the behvaiour (meaning the downstream
code needs to use the API correctly) or fix the implementation bug it
exposed.
BTW, I saw that you posted a new snapshot of SDO a couple of days
ago. I
wasn't sure how best to choose when to post a new snapshot or how to
communicate an imminent update. Is there a best practice for
choosing when
and how to deploy new snapshots?
In general, anyone should be able to redeploy a SNAPSHOT at any time
- some communities even do it automatically, say nightly. They are,
by definition, unstable versions. IIRC I did it because something was
trying to use SDO and either couldn't find the right version or had
problems with the online version.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
