I prefer to have 1.6 as the next release, but I can live with calling it 2.0.
My only ( very strong ) requirement is that each change must make the best possible efforts to preserve compatibility with 1.5, and each individual change must be aproved by majority vote. And I would certainly opose replacing the entire codebase or making arbitrary changes just because we call it 2.0. Each ant release ( starting with 1.0 ) made changes - while officially trying to be as backward compatible as possible. I don't think that 'allow top-level tasks' or 'classloader fixes' or 'import' or 'antlib' or 'sax2' or 'jdk1.2' would require a 2.0 name, but I agree that maybe the combination of all those may fit the label. On the other side, I believe ( and ProjectHelper should prove it if you don't want to believe me ) that even 1.5 can support most of those new features. It would be much better to provide them now, as 1.5 'add-ons' and gather user feedback on each - and use this in 1.6/2.0/whatever. In any case, the name of the next release and the content must be determined by vote - and until a release plan is voted we should continue with the work on the main branch and make proposals/vote for each major change. Costin On Mon, 22 Jul 2002, Steve Loughran wrote: > Here's my list what I'd like to see in the next version of ant. > > Before doing so I want to take a moment to reflect how successful ant1.4 has > become -it is now the standard build tool for java projects, and it has also > shown that nearly 10+ month intervals do work as a lifespan of what is now a > fairly mature piece of code. We've also just launched ant1.5 at what must > be, thanks to everyones efforts but Magesh's most of all, was our most > rigorous release process to date. > > I fear that Ant is now mature and widely used enough that we will have to > sporadically release point versions of ant1.5.x while working on the next > version. Which is actually good in a way, it stops people being forced to > use beta versions just to fix a bug. > > Doing so thus gives us a chance to do some radical stuff, though of course > gump runs off CVS-head which may be an issue. > > What do I want to see in terms of task evolution: > > 1. <hostname>, including nslookup of remote addresses > 2. try and get the http tasks to work with httpclient, and so work properly > 3. I also want to be able to make soap calls from inside ant; that would be > slick for some deployment actions > 4. <latex> and <pdflatex> tasks in some optional-latex package > 5. get the .NET stuff up to snuff for better wsdl import testing of axis > services; better handling of references, multiple source files, support for > J#, all in the optional-dotnet package > 6. pull in the <CC> tasks from ant-contrib. Even if the tasks are in an > optional package, I'd like to reuse the library and defines stuff in the > .NET compilers, so the datatypes need to be common. > 7. Java1.4 support more broadly, perhaps with an <assertionset> type to > describe assertions to enable/disable > 8. a better sub build task than current <ant>. We cant change that for > compatibility reasons but <subbuild> with forking, better defaults, filesets > and the like would be cool. > 9. xml schema support. Which means some way of adding local schema URLs to > catalogs/dtd mappings > 10. Easier to contain ant inside guis. I hate getting optional tasks to work > in any GUI ant container, it is always so hard. > > Underneath all that, I want so say that maybe it is time to move to java1.2 > and clean up all our classpath stuff, so that we can move to a good packaged > world, get rid of so much classpath confusion, etc. Which means that we move > to something called ant2.0 > > If we spend all our life firefighting 1.x issues, then we will never be able > to move to the 2.0 codebase. And so Conor's action, deleting mutant from > cvs, has made it clear that there have been multiple protos for 2.0, and yet > the main ant branch has been too busy evolving to make any revolutionary > jumps. > > Yet the permanent '2.0' is coming pressure has stopped us evolving ant1.x in > ways we'd like, because there is pushback on the 'this wont be 2.0 > compatible' theme. Example: Jose-Alberto's antlib proposal. > > So we are doubly stuck: we arent moving ant to a 2.0 codebase, but the fact > that such a migration is planned stops is fixing some things in the 1.x > platform. > > We need to move forward, one way or the other. > > I'm think we ought to give priority at this early post-1.5 point to decide > what the focus of development should be for the next round, simple evolution > of ant1.5 or whether this is a good time to sit down and move up to starting > on ant2.0 in earnest, maybe using mutant or myrmidion as foundations, or (as > Costin suggests), to evolve what we have today, but either way to rework > enough of ant to make it better than it currently is. Better in terms of > scalability, flexibility and usability, yet still being very backwards > compatible with the existing build files. > > Compatibility is always the issue. With a 2.0 number we can get away with > incompatilbities that are obvious and easy to fix, but we should still avoid > any subtle incompatibilties that only take time to show up, as users wont > catch them. > > Comments? > > -Steve > > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
