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
1.7.0.1 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
time).
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
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
