0.9.7 wasn't incompatible for me. "Works for me" means just that -
and it did.
But here's a reciprocal question: How is it that no matter how many
release candidates we seem to produce, and no matter how many times
we ask users to please try out and file a bug if they find issues
with one of those release candidates, we always get comments that say:
On 21 Jun 2005, at 16:35, Andre Teubner wrote:
Please remember, we only relaced castor.jar in our app and replace
depracted JDO code with JDOManager. No other changes. I wonder why
every
new version is incompatible against predecessors.
Actual API changes are coming in the pipeline, alongside fundamental
changes to transaction, changes to polymorphism, major refactoring in
the pipeline for a range of classes to make extension easier and,
ideally, improve code reuse and make the system less fragile.
But we're never going to get there if the community doesn't pitch in
and help out by helping us verify that a release works.
We have been using 0.9.7 here, in one form or another (arguably, with
bits of 0.9.9 in it) for... about two months; several million page
hits per day filter their way through the JDO layer. When it breaks
badly, we'll spot it, but only on those areas of the codebase which
we cross - and there are a range of areas of the codebase we *don't*
cross.
Every user is like that: Everyone touches different parts of the
codebase, relies on the perfect operation of a different set of
conditions. Moreover, lots of people are using differing versions of
the JVM, different SAX parsers, different databases; each of those
can result in a different set of behavior and a different set of
results.
And beyond that, there are different sets of API: You can use the
Unmarshaller, the static method on a generated object, or you can ask
the unmarshaller for a content handler and do the SAX work yourself
(off of a set of pooled SAXParser objects, for example - a good idea
for those looking for performance boosts in environments with lots of
little parsing going on. Bigger question: Should we add a commons-
pool dependency and start doing a lot of that pooling ourselves, as
well, inside Castor? There's lots of places where we can probably
reuse underlying structures...)
But we only get working code by testing and knowing that it works; we
only get there by testing those code paths, and we only get that
through one of two mechanisms: Test cases and you.
Test cases can only get you so far; and that's one of the reasons we
beg and plead that if you do file a bug, or have a problem, provide a
test case for your environment - if it was honestly so broken that
nothing at all worked, it never would have been release; all bugs in
releases are, almost by definition, edge cases, as one of the core
developers, in one form or another, is *probably* already shipping a
product on the unreleased version of your version long before you
have a version in your hands. So if you've got a problem, you've
found an edge case - telling us "it's broke" won't necessarily help
us find it. File a bug, file a test case, and help us improve the
product long term.
And then there's releases.
RC means just that - it's an RC. Like many other projects, including
Tomcat, it's released when the community says it's not full of bugs.
The correct time to tell us that it isn't full of bugs - or for that
matter is - is during the Release Candidate. That's what RC is for.
If you don't help us test the RC, and find a bug in the release, how
can you have expected us to find it? By definition, it's an edge
case - like the recent discovery of some delete-and-readd-within-
transaction behavior/bug that just got fixed and targeted for 0.99.
If you want stable product in your environment, and you're relying on
stable product in a product you use, you have to start committing the
time to ensure that it works for you. It's not much to ask - many of
you who complain the loudest are folks who are running commercial
businesses or non-commercial organisations with this as a backend,
for whom breakage is a real issue.
If breakage matters to you as a business or organisation, then
helping us deliver a solid product is in your best interest; all we
ask is that you test an RC, and file bugs and test cases on problems
you find during RC or your day to day operations. That's it. The
core developers - Werner spends countless, thankless hours on Castor,
for example - are willing to take the kick in the balls, on the
occasion, to make sure those bugs get fixed ASAP in the codebase.
We don't ask that you fix, though we'd like you to; we don't ask that
you understand the codebase, as we sometimes struggle with that
ourselves (insert smiley) - all we ask is that you help us make sure
that when we do release, the release works.
That means helping us make sure that our (the community's) product
works in your environment, with your codepath through the codebase.
Help us make these releases more stable; help us make sure they work
for you by testing release candidates. If you don't test an RC, you
can't be guaranteed that it will work in your environment as a
release. Every one of you is unique - as such, every one of you is a
valuable and necessary member of the release process for Castor.
Test an RC, and help make the product better - fail to do so, and
it's like abstaining in an election; if nobody votes, then the
handful who do get their way. In this case, the handful who did test
and use the RC gave it a green light - it worked for them. If that
pool of people isn't representative, because you didn't vote, then
don't let it happen again.
Test an RC. Wear a T-shirt that says "Have you hugged a Castor
developer today". And file a bug, and we'll do our best to fix it.
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
