On Mon, 8 Jul 2002 dion@multitask.com.au wrote:
> For me an acceptable process would be that the committers decide to put
> Ant 1.x into maintenance mode and choose what to do with the existing
> proposals:
> - Vote for one as the usurper
> - Vote for neither, and migrate the functionality into Ant 1.x as
> soon as possible
> - Vote for both, and merge into a new proposal.
I have another one:
- vote for neither, and migrate functionality in ant1.x incrementally and
with a lot of thinking ( instead of 'as soon as possible' ).
It seems that's what we are doing anyway.
As for 'maintenance mode' - we kind of are in this mode for many
parts of ant ( the core ), and that's IMHO the reason ant is
successfull.
> > What do you mean "backward compatibility"? Ant1 is mired in backward
> > compatability! As for scripting, I presume you mean script-like tasks
>
> I mean breaking with backward compatibiliity.
>
> Mostly not in the build file :) But simple things like looping and
> conditional processing are very important., the if and unless just don't
> cut it as the build gets bigger.
If you want to develop an xml programming language - nothing can stop you,
but please don't call it ant ( or ant2 ).
> > Previous discussions have suggested using Gump as a minimum acceptance
> > criteria. I've certainly tried to have Mutant work effectively with
> > Gump. Again the problem is not having an agreed process. Indefinite
> > postponement seems to be easier than a decision.
> But postponement really is a decision. As time goes by I've seen things
> planned for Ant 2 move into Ant 1 and the core classloading and
> optional/built-in issues get worse.
I hope ant1.6 will get one of the current classloading / optional
proposals - if not, then 1.7 will certainly do.
I don't see anything technical to prevent doing that ( in a backward
compat. way ). Spending time on finding the best solution is good.
> > I sense the suggestion that Ant is suitable for small projects only.
> Definitely not, but looking at things like Tomcat's build file scares me
> big time. The other thing is the sheer amount of duplication across build
> files without standardisation, e.g. jdk1.2/3/4 compilation exclusion, on
> vs offline etc.
I agree with that :-)
However tomcat is a complex project - and most things in the build.xml
are there because something needs them. I doubt ant ( or any other
build tool ) could have all the tomcat needs covered ( and if it
does, it'll be a very complex tool, since few projects need all that ).
> > With respect to "oddities of history", it is probably also worth asking
> > what is the acceptable level of backward compatability breakage in
> > moving from Ant1 to Ant2. For some people, no break is acceptable even
> > across a major version number increment.
> Embrace the change :) Ok, I'll bite... What is the acceptable level of
> backward compatibility? Build file? API?
Gump running all the existing projects without error is the minimum.
( that includes running all existing user-defined tasks in
jakarta/xml/etc ).
And no change just for the sake of changing ( like name changes,
cosmetics, etc ).
Costin
--
To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
|