<snip>
> Didn't mention that if you found a bug and maybe even help to fix it
> or you're experience help correcting a wired behaviour, you could
> contribute something back to the project as well.
>
> Regards
> --
> Massimo
Fundamentally though, I'm not in the business of debugging Tapestry.
I've no objection to contributing things to the community (take a look at my
tabset control, my switch/case implementation, or my secure direct links
code), but that's something I do as an adjunct to, rather than a core part
of, my work.
So if I happen to trip and fall down the stairs into a Tapestry bug
and fix it, sure, I'll put it on the JIRA. When I'm working on a commercial
product though, I'll never go out of my way to expose myself to additional
somebody else's bugs in order to fix them. I just can't afford that big a
potential hit in my personal productivity, whatever the advantages to
society at large.
Likewise, as others have mentioned, the Tapestry API does change
from Beta to Beta (and from 3.0.3 to 4.0). For folks like me, who come from
the commercial enterprise software world, that's a huge blinking red flag
screaming "STAY AWAY!" If I changed *even one* API call on a commercial
product, my customers would drag me through the coals. I *might* get away
with it on a major version number release, but I'd have to document the
willies out of it and even then I'd have dozens of irate folks calling
support and beer thrown at me at the User conference.
Even had a product rejected from production because you changed the
collation order of the oomlaut character? I have :). Ever had to make a trip
the upper peninsula in winter to personally apologize for deprecating a
1970s era MVS specific function your largest customer used extensively? I
have :).
NON TAPESTRY SPECIFIC RANT ON:
I understand and accept that things are different in the open-source
world, so I don't (usually) grouse about it, but at an emotional level it's
still a huge subconscious risk factor. The velocity of change is so fast on
a project like Tapestry (or, even more accurately, like BIRT) that my
immediate response is A) pick stable version B) don't change it until
absolutely necessary. It's not even the change, specifically that sets off
my "danger Will Robinson"-meter, rather it's the *incompatible* changes.
Even something as mature and "stable" as Hibernate has been known to
break stuff between x.x1 and x.x2 (if I recall going from 3.0.3 3.0.5 took
me two days because something or other changed). I mean really, making a
non-backwards compatible change in a major version change is risky enough,
making it in a minor version change is a head scratcher, but doing it in a
bug-fix *hundredths digit* change :)?
RANT OFF:
In any event, my point is that different people have different needs
and expectations in the software packages they choose to use. I have a very
high need for stability and predictability, and a low tolerance for change.
Partly this is the nature of my work, partly it's simply my programming
personality; once I get something "done" I want it to *stay* done come hell
or high water.
So, if you've a high risk tolerance and want to develop on Beta's,
more power to you. Seriously, that's great because it's because of folks
like you that Beta's get well tested and (ultimately), folks like me get
stable code. You have to recognize though that my subset of the developer
community is *never* going to do any actual work on anything with the word
"beta" in its name. Our life experience simply teaches us that it's an
unacceptable risk.
--- Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
