On Thursday 13 April 2006 21:25, Jeremias Maerki wrote: > On 13.04.2006 14:58:04 Peter West wrote: > > On Thu, 2006-04-13 at 12:11 +0200, Jeremias Maerki wrote: <snip/> > > That means that > > changes to Commons have the potential to break both FOP and Batik > > trunk builds. For those builds on both sides, then, there will need > > to be Commons versioning information. > > That's true. As soon as both projects use Commons, we will have to > be careful about changes. If we really need some kind of versioning > info remains to be seen. One tool that helps us here is Gump. I > wonder what the others think. >
Not sure I really understand what the problem is or if the problem is any different to any other project that publishes an API. Once you have published an API (a contract) and you have customers using that API one must be very careful about backwards compatibility and changes to the contract. Any published API "suffers" from that constraint and nothing special here about xmlgraphics-commons. So the decision if it is worth the "pain" of having to maintain a published API vs the gain in re-useability and loss of duplication by having a commons project was resolved when the PMC voted in favour of establishing this project. Regarding versioning, IMO, every published JAR should contain sensible versioning information. Regarding version dependency management outside of formal releases yes that is an issue especially if one assumes that there is a tight coupling between FOP and Commons development, e.g. FOP trunk may require a non release (but non trunk) version of Commons to work. That could possibly be handled by tagging the appropriate version in Commons SVN (have a "floating" FOP Trunk label on the Commons SVN tree identifying the Commons version currently recommended to be used with FOP trunk). > > > > Peter > > Jeremias Maerki > Manuel --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
