On 2/23/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > > I don't understand this; don't the component APIs matter? Do > > you truly believe that MyFaces should feel free to make any change > > at any time? > > The component API's matter but I don't hold the components to the same > standard as I would a language or framework. I think its unrealistic > for a user to assume that an entire suite of components won't have an > API change even years after release. I want to reiterrate how we > should not take these changes lightly. We should try our best to > limit them.
I agree that its unrealistic to say nothing changes even after years of release, and I wouldn't want to go down the core Java API path where deprecated APIs must never die... It seems like our main disagreement is *when* things may change. I really believe that APIs should change (in non-backwards-compatible ways) at well-defined points in the product lifecycle - not at any release. (And, to be clear, I also believe that the MyFaces APIs aren't yet ready for a lockdown of any sort, and still can and should change for now.) > > It's not fair to say "no one's forcing them to upgrade": if you provide > > three features and ten bug fixes they need, they are forced to upgrade. > > We will work with the users to help them upgrade and provide advance > warning when such a change is envisioned. We even give them a chance > to object and convince us not to make the change. We also make the > source available so that they can build their own version of the > component without the changes they want. Most of these luxuries are > not available to the typical purchaser of OTS software. I'm not talking about commercial vs. open source software. There are many open source projects that are very conservative with API changes. JUnit doesn't just change APIs with any release; they wait 'til major version numbers. Maven waited 'til 2.0 to make major changes. I don't remember what policy Struts had. Heck, I remember a lot of people getting annoyed because Commons Collections changed their APIs - and that *was* at a major release. > > I agree that *at this point* in MyFaces, it's critical to fix > > APIs to do the right thing. But at a certain point, if you > > want people to use your software, you need to give them > > some level of confidence that their code's not going to break > > every time they upgrade. And sometimes that means > > saying "nice idea, but it'll have to wait 'til 2.0." Or providing > > an uglier implementation, like an ExtendedTreeModel subinterface > > that adds the additional methods without breaking existing > > users. > > If we follow a conservative approach to changing interfaces then I > think our users will understand and accept that approach. Again, this > should be rare case but not completely rigid like Sun is with their > languages or specs (for understandable reasons.) I agree we shouldn't be completely rigid, but the question lies in defining what's meant by "a conservative approach". My conservative approach is - at major releases. > > I think "there are no customers except for us" is sophistry > > that dodges the issue. Surely you want others to use > > your software? And you care when they complain? > > If not, why have a [email protected] list? > > Of course we want users to user our software. But if 90% of the > "customers" would benefit from an interface change and the other 10% > object strongly, the majority wins. Particularly if the 90% are the > people doing all of the work (whether is the coding, documentation or > support.) The 10% have no standing because they did nothing but use > the free software and tech support. Obviously we want to avoid this > situation, but if it comes down to that, that's the way I see it. > Ideally everyone is happy but I think you would agree that we won't be > able to please everyone - no matter which approach we take. It's never as simple as 90%-10% - that's not how things work out in practice. Because the questions revolve around: - Do I make the change, but in a backwards compatible but somewhat uglier way? - Do I make the change, just not right now? It's not just as simple as "yes or no". And do the rest of the MyFaces developers really not care about those users who aren't ponying up development time? Do they truly have "no standing"? Legally sure, but emotionally? I like it when users say they like my software; I don't like it when users say they hate some bug or missing feature. > > If it isn't rock solid, it's not a public API, and should be > > documented as such. I totally agree that priorities need > > to be set! One consequence of "not enough time" is > > admitting that some APIs really can't be made truly public, > > because they're not rock solid. So make that statement > > explicit instead of leaving users in the dark. > > Who is documenting it as such? I don't recall reading the words "rock > solid" or "guaranteed not to change" anywhere in our documentation. Do you also have documentation saying "anything may change at any time, this is all bleeding edge, you might not want to use it in production software unless you're reaaaaaly careful"? There is, at a certain point, an implicit assumption that you're not going to break code when users go from 1.1.8 to 1.1.9. > Maybe we could put a disclaimer on our website or something but I > think our users are trusting that we will do the right thing and break > backwards compatability only as a last resort. > > The commons (now shared) stuff is pretty volatile and I would agree we > need to be clear that this stuff is for internal use only. If we do > ever have a commons project to be used outside of MyFaces that really > does need to be a rigid API. I agree. > > Yep for #3 - but I really think that the issue of solidifying public APIs > > is extremely important, and we can't just say "this is open > > source, so it doesn't matter". Software is software; reusable > > libraries are reusable libraries; how they're developed doesn't > > mean we should lower our expectations. > > I think the fact that it is open source makes a difference. Open > source is more fluid then commercial software development. Our users > are also generally more sophisticated. They like to work with the > cutting edge, hence the popularity of nightly builds. They know the > risks. We can get more components out the door faster if we don't > obsess over every detail of the interface before releasing. At the > same time, we do have the sandbox where components mature before > release. So nothing is done in haste. I think this is a nice > balance. That's all true now - but at a certain point, wouldn't you like to see MyFaces go beyond the "cutting edge", "more sophisticated" developers? JSF is supposed to be easy to use, the J2EE web framework for the run of the mill developer, who don't have to "know the risks". (Nightly builds are a good thing, don't get me wrong, the sorts of developers - like me - who can take the pain of a nightly are great. But they're not the only sorts out there.) The only way to get there - if MyFaces wants to - is to find a path to get to a truly stable API. I think that should be a top priority - identify a subset of the MyFaces API (the components and any direct, public dependencies of the components, like model APIs) that should be stable, and spend serious effort getting it exactly where wanted, and then say "OK, 'til 2.0, you can rely on this." That's what every great shared library project - open source, commercial, *anywhere* - needs to do at some point. -- Adam
