ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Jackson" <>
Subject Re: ant 1.7.1
Date Sat, 12 May 2007 03:45:52 GMT
Hi all,

> I can see this is a serious issue; if you follow the links its causing
> problems with eclipse 3.3 apps
> options
> 1. let Eclipse backport it themselves.
>   -no work for us, but we end up splitting bug reps between the two
> teams, and there's still some issues with the locator stability to deal
> with.

I can't see this working long term.  Short term fix that seems to
cause us (ant) less hassle but in the end will probably produce more
work -1 for this from me

> 2. rush out an ant1.7.0.1 without adequate testing
>   -I dont like this, because I've been in projects before that shipped
> things to meet WebSphere's needs, and it hurt in the end (Axis, BTW).
> Quality gets dropped at the expense of timeliness, but you end up
> getting all the support calls anyway

The current trunk would have to be locked down, we'd have to make a
release plan, and we'd still have to go through at least one beta
cycle - at best I can see this taking 4 weeks (1+week for the release vote, 1+ week to get fixes in 1+ week for testing, 1+ week for
final vote).  Is 1 month+ still timely enough for eclipse?

> 3. Do an Ant1.7.1 with no features, just the current code with tests all
> working, including stuff for the locator.
>   -gets the jscp patch into the field
>   -gets autoproxy working
>   -any other minor fixes that have surfaced since ant1.7.0
> we could still run a tight schedule, but with a single beta
>   -any other critical fixes to go in?
>   -cut a beta release for june
>   -ship in july

This is still pushing it close, if eclipse is really relying on us for
the locator fixes, then I think this is the only sensible option -
which really annoys me :(.  We will be shipping a very minor upgrade
with *1* fix that helps a dependent project, all because windows sucks

I'm still concerned about the schedule even with a july release
penciled in - if we go for this, we need to triage bugs/features over
to 1.7.2/1.8.0 quickly so we can focus on the things that will go in
for july.

+0 for this option, definitely the best of a bad lot, but by no means
what I personally wanted the next release to be.

> If you look at what I've been putting in the wiki for Ant1.7.1, there's
> a mixture of feature creep and packaging; most major ant1.7.0 defects
> have been identified already and should be patched.

The deb packaging I think will have to wait to 1.7.2 (unless I
suddenly get a load of free time and everything I code works first

> We could move all features until Ant1.7.2, make the 1.7.1 the simpler
> bugfix release, with less trauma all round.
> Thoughts?

I think it's the only way to help out the eclipse guys without totally
screwing up the next release - we have to be realistic and decide what
we can get done in the next month in terms of fixes & testing, and put
off anything else until after this fix release goes live.  I'm
currently using the trunk version of ant-launcher to get around the
problems I encountered with the URI, so in my testing the issue within
maven should be closed, and Darin already tested the fix from the
nightly builds and seems happy with it - I guess we just have to be
careful to not introduce anything in the next two weeks while we are
fixing / testing


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message