Mike, the problem with this approach is one of forward compatibility.
Let me explain. The ExternalContextUtils in the MyFaces commons, when it existed in Trinidad, had api's for handling request input streams and whatnot because the ExternalContext did not. If someone used that API and then wanted to run their application using JSF1.2 and the 1.2 version of the commons, they would need to do a mad scramble to get the proper api's added. Furthermore, if when you design an API for a 1.1 branch, and you don't take into account later versions of JSF, you increase your changes that that contract will have to be changed. That, for instance, a particular piece of functionality will not be duplicable in a later release. Forcing consideration in later branches helps eliminate this as a possibility.
IMO, most new development should be done on the later branches and posted to earlier branches as appropriate. That's why I'm a proponent of having a trunk which reflect's the latest code and branches which get backports as needed. If the libraries are allowed to not be "forward" compatible, they will, essentially, become useless for just about anyone to use. I know I for one would be reluctant to use an open source project that I know will require a lot of work before I can upgrade. I would rather just develop something in house.
That said, I'm far less concerned with what happens on outward facing projects then I am with infrastructure projects. If API's do not allow upward mobility in infrastructure, EVERYONE looses in the community. Backward compatibility? Presumably not, because the old api's would still function the same, they just might become feature limiting.
Ultimately though, the commons project has to support the policies of the "strictest" outward facing project, unless it is intended for that project NOT to have to depend on commons.
Scott Mike Kienenberger wrote:
Let's not forget that working on open source software is quite different than working on proprietary software. For open source, you work on what you need and you share what you've done with others. Some people need JSF 1.1 and will be working there. Some people need JSF 1.2 and will be working there. Some will need 2.0. Keeping it all consistent would be ideal, but realistically, everyone needs to work on what they need. To say that no work will be allowed on JSF 1.1 is not helpful. Yes, it'd be great if everything applied to one branch can be applied to another, but if someone is still working on JSF 1.1 fixes and features, they may not have access to JSF 1.2 or 2.0. My suggestion is that we keep this in mind and allow for some flexibility. It may be that some work committed to 1.1 remains as a JIRA item until someone needs it in JSF 1.2 or 2.0. And a bug fix to 1.2 may remain as a JIRA item for 1.1 until it's needed. As an example, I'm doing a lot of work with a legacy app these days (which is why I'm not actively doing JSF development) and it uses Cayenne 1.1. That's now 4 versions old as Cayenne has transitioned from 1.1 to 1.2 to 2.0 to 3.0. I don't expect the cayenne community to support my needs by back-porting all bug fixes, but I do have the ability to back-port and maintain those fixes myself as a developer, even though the branch is not officially supported by the project. And at the same time, if the problem I fix is still an issue in 3.0, I'm not expected (or required) to make sure that every version of Cayenne after 1.1 has that fix applied. I would open a JIRA issue, but since the architecture is quite different for later versions, it would be up to someone using a newer version to solve and apply it (with or without the code I used to fix it). On the other hand, I would typically try to also fix it for 1.2 since the ease of applying such a patch is greatly reduced. Myfaces Core and Tomahawk has always been very weak on providing bug fixes for older versions. If anything we should be trying to make that task easier rather than more difficult.
