Steve Loughran wrote:
I worry about releasing any change to code without giving it time to stabilise and beta test. Last minute "this won't break anything" patches always break something. Always. At least in my experience.
If commons1.4.0 is incompatible with shipping <ftp> then yes, we have no choice but to upgrade. But if it is a feature enhancement, then it needs
to go into CVS_HEAD
Very legitimate concern. However, this is a trivial change.
so are all changes that end up breaking things.
Ant1.6.4 is really Ant1.6.3a; a late fix for stuff that wasnt caught in the beta test. I am really, really, reluctant to do anything that could break stuff. If ant1,6.4 ends up broken, we have to release an Ant1.6.5 two weeks later, there is more pressure for last minute changes, we introduce new bugs, never stabilise, get a bad reputation for release management, etc, etc.
If you look at the commit log, you can see that I tend to avoid committing my own changes to the 1.6.x branch either, because I like to work with things myself for a bit. Once something is in the public API of Ant, we cant remove it. So we need to get it right, And that means being strict about last minue commitments. Indeed, there are three things I committed that I think might want to go into the 1.6 branch, but but I'm not going to do it
-java1.5 class passthrough changes to JavaEnvUtils -java1.5 settings of default rmi compiler options -that switch to WeakHashMap.
Why am I not committing them? Because nobody is complaining about them, even though they are clearly bugs with trivial fixes.
-Steve
(NB, I'm not the release manager, but note that I'm fairly relaxed about changes compared to someone I've worked with. Ruthlessness is a wonderful thing when it is time to get something out the door)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
