ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Patch Audit
Date Mon, 06 Aug 2001 06:29:08 GMT
On Mon,  6 Aug 2001 15:56, Conor MacNeill wrote:
> Peter,
>
> > > 2. Regexp replace
> >
> > This is mostly used to replace constants in file. We should
> > instead encourage
> > people to do a filtered copy + exclude to do this (like ant build file).
> > There is probably other legitimate uses though ... can anyone
> > think of any?
>
> I know Brendan is working to eliminate unnecessary white space in JSP/HTML
> files as part of a deployment. That would be one example of a regexp
> replace operation.

+1
sounds good then ;)

> > All the other ones that I have already -1 ed or said that I would
> > -1 (lowcost
> > antcall, foreach, lazy classloading etc) still stand for stated reasons.
>
> OK, I haven't seen those all. For example, I can't see any reply to the
> patch on lazy classloading:
> http://marc.theaimsgroup.com/?l=ant-dev&m=99573595724106&w=2
> I haven't looked at in detail, myself but if I missed your response, can
> you please give me some refs - thanks. I'd just like to record the
> disposition of all the outstanding patches.

oh okay .. I went from memory - that patch I like. The other discussion that 
delayed class initialization was what I hated ;)

> > However I am really concerned about you wanting to add more functionality
> > before a beta release.
>
> Well, I'm not sure when would be a better time to add functionality.

right after a release ? ;) Then we have a whole cycle that we can use to tune 
them and we don't have to keep everything 100% backwards compatible in that 
period. We are free to experiement and do the "right thing" rather than what 
is thought of first.

> > Most of this stuff while good (dependset,
> > configure,
> > async exec, input getters, C++ support) is not going to be
> > guarenteed to be
> > well tested or reliable.
>
> Fair enough. What do you suggest is a reasonable period after a feature is
> added before it can be considered a candidate for a release? 

depends on the feature. When the majority of committers are comfortable in 
saying feature X is stable and are willing to support it then we release it. 
However things that haven't even really been tested should definetly not be 
considered.

> We have made a
> number of changes recently that can be considered new functionality. Are
> you suggesting we wait for these to bed down, or should we take a branch
> for 1.4 from some earlier time?

You mean container and classloader changes ? Don't know - haven't being 
paying a lot of attention to code changes ;) ClassLoader changes are more 
"risky" than other changes and you will almost certainly break some code 
somewhere. However I haven't watched it closely so don't know.

> > If you recall some of the limitations of
> > current ant
> > resulted from exactly this behaviour (people adding "minor" enhancements
> > before a release without knowing full consequences). I think it should be
> > bugfixes only before a release.
>
> I don't really recall that. I'm not sure exactly what "limitations" you are
> referring to here. 

well IIRC property behaviour from mutable to immutable was a last minute 
change before a release ... I think ... not sure my archives have been backed 
up to CD and it too much effort to look them up. I also seem to remember 
other things like addition of if/unless to targets while it occured in the 
"middle" of a cycle was changed just before a release.

> Can you give an example? Anyway, the policy I have used
> in previous releases is to accept all functionality up to the beta, and
> then only bugfixes in the beta period until the beta is considered stable.
> At what point, therefore, would you suggest we move into the "bugfixes
> only" stage.

Not so much bugfixes only but only well tested features. New tasks that are 
small and well understoond (say regex replace) should be added but things 
that change the patterns and forms used in building ant files should be given 
more thought and more time to simmer.

> In other words, lets state the process we are going to use for deciding
> when to include functionality in releases.

I guess I haven't stated my position explicitly but heres my opinion (note 
that I am not trying to get ant1.x to work like this).

* Ants "engine/runtime" should be released independently of task libraries 
and occurs when it is absolutely necessary
* task libraries released when they are ready
* we can have "umbrella" releases that just aggregates libraries together 
(like J2ee aggregates other apis like ejb/jms/etc)
* the release cycle should be *much* shorter and more regular
* ant committers should not be sole gatekeppers of tasks - they can be 
distributed and maintained separately/independently as required

So I guess my opinion is coloured by this. Because ants releases occur so 
infrequently I don't think we should just full it chockers each time. I would 
prefer incremental expansion (and possibility of retraction). I do not think 
it would be in our best interests to introduce alpha quality products into a 
stable release of ant. Instead we should accelerate release cycle of ant and 
test things that way.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Mime
View raw message