I disagree with your points regarding validation errors targeting a developer audience rather than end user. First, validation errors are not likely to be the result of a programmer error, although yes, if you do supply the wrong mask, it might prove useful. More importantly, previous versions of Tapestry messages were end-user friendly enough to be used as-is AND they were already internationalized into a number of useful languages. It is pretty unlikely that there aren't large numbers of users using the default messages, precisely because they used to be more than up to the task. Again, the issue is an UNNECESSARY change in behaviour on a point release without any kind of backwards compatibility mode. And on that point, most commerical and many open source frameworks most certainly do go out of their way to provide such stability across releases. Traditionally, version numbering itself was intended to be used to indicate this. API changes generally are reserved for major version changes. The importance of adhering to this is that even the non-technical members of a development team understand this point, so it is always surprising to them that there is as much work involved in upgrading from 4.0 to 4.1 as there is.
Incidentally, no one is asking open source to be free. I've been building software based on open and closed software packages for 15+ years (soft. architect or senior developer at Cisco, Akamai, Software.com/Openwave, Dreamworks, Valueclick, the UN, developer at various others), and I am well aware of what open source offers compared to commercial packages. In fact, when I was choosing Tapestry over various and sundry other frameworks, one of the things that drove me to Tapestry was the maturity and stability of the codebase. I went out of my way to look at the differences between 3 and 4 specifically so I could see what I could expect during a major version upgrade, and I liked what I saw. The API remained largely consistent, the changes in the API were well documented and, more importantly, well-justified. And perhaps most importantly, it seemed to have a supportive _community_ of developers who use it, which, as we all know, is usually the single most important factor in the usability of an open source package since the documentation is almost always greviously deficient in open source projects (although tap is better than most in that regard). As a member of that community, I think it is our responsibility to express our opinion of the direction the product is taking. HLS and other developers don't have to pay us the slightest bit of attention, of course, but if the community doesn't express a preference, what we wind up with is a framework that caters only to the unique needs of the developers which can often be fairly out of sync with what a more 'average' user requires, specifically because the developers have such deep familiarity with the API. The 'feature' in question is a nice example. It benefits a small number of users at the expense of what I imagine is the majority. So yes, I see Tap 4.1 as something of a 'Jesse special' which provides some of the changes he most wants to see, potentially at the expense of general usability of the framework for others. That's his perogative, of course, so long as the other developers agree, and I don't read the developer list often enough to be even slightly aware of what the developer process is like on Tap. Unfortunately, I don't have the cycles right now to jump in and start hacking on the tapestry source myself right now, especially 4.1, since I'm not using it. However, as a potential user, I certainly want to speak up and attempt to be heard so that 4.1 can be the best possible upgrade for Tapestry users of all stripes. Open source may not promise a no-cost platform for users, but the concept of an application development framework should promise a certain amount of stability, since its entire reason for being is to ease the development process. When was the last time the gnu C library released an API that wasn't source compatible with previous versions? What about the JDK? I actually think that a framework like Tapestry benefits by not adhering to old api in every case. The benefits of the change often outweigh the cost. But this isn't one of those cases. Not only are the benefits questionable for many users, but it shouldn't be difficult to provide support for users the old api as well. Trading application complexity for an unstable framework isn't a useful tradeoff for anyone, unless you are able to abandon development of projects built on older versions. Forking the framework source is just as inefficient as building your own framework and simply living within its limits isn't often a viable solution for long term devlopment. Listing projects that got stuck on old platforms due to platform instability doesn't support your argument. It reinforces mine. I'm sure the folks at the companies you listed would prefer to be able to upgrade and utilize newly available features, but they are unable to without incurring a cost they don't feel they can pay, either in money, time, or product stability. That isn't something a 'framework' should be proud of. But given that at least one of the frameworks you mentioned wasn't even a 1.0 version, it shouldn't have come as a surprise to the development team, and I'd hope that fact was on the table before they ever decided to use it. It certainly would have been a major bulletpoint when deciding on tools if I had been driving development. It doesn't bother me when dojo makes an api change, precisely because the thing has a 0.4 version number. I know when getting into it that that is a risk, and when I accepted dojo into our codebase, I committed to supporting dojo's api changes within our own codebase. I have different expactations when using a framework that is numbered 4.x. So if Tapestry is going to become an unstable platform, I'm just going to wind up using something else instead. That's a big waste of intellectual energy and developer cycles for me and my team, so it is something I'd prefer to avoid if possible. More importantly, if this impacts other development teams the way it does mine, then I worry about the community that supports Tapestry, which, if it goes away, makes Tapestry a much weaker framework for all but the most knowledgable users (the developers, mostly). That's fine, but it defeats the purpose of an application development framework, which is useless if it doesn't actually assist in application development for users. And incidentally, I don't really spend that much time writing these emails. After 30 years of piano, 15 years of full time computer use, and 5 years of dvorak keyboarding, I type pretty fast. My emails tend to get long before I even realize it. Sucks for my readers ;-) --sam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
