From: "Tim Dawson" <[EMAIL PROTECTED]> > Adam, > > It depends on how you define backwards compatibility. If all we're concerned > about is that the same build.xml works, then I have a proposal. Why not > create an "experimental.jar" to go along with the "optional.jar" for new > tasks/typedefs, and by convention use a prefix "x-" for the element names. > If someone uses experimental types or tasks, then they are accepting the > work of fixing the build.xml file *when* (not if) it changes into the final > form. > > For example, if we start with: > <x-antlib file="blah/blah.jar"/> > > then another idea is added to the mix: > <x-antlib2 location="blah/blah.jar" useXML="true" useTools="true"/> > > We throw this out in Ant 1.5 (for example) the community discusses, > thrashes, etc. and finally we merge the two, remove <x-antlib> and > <x-antlib2>, and release <antlib> in Ant 1.6 as: > <antlib file="blah/blah.jar" useXML="true"/> > > We could do some of this actually right in Ant 1.x. >
I think this is a wonderful idea. This will allow us to experiment and still give some sense of consistency in the product. > Again, this only works if the issue is the build.xml. When trying out deeper > changes to core, e.g. classloaders, introspection, roles (cool idea!), etc. > then yeah, those are issues that would probably require creating a few > branches, trying them out, and moving from there. The only problem with > branching a lot of different code-worded projects is when people form an > attachment to one way or another and you have problems merging them back in. > Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
