On 9/28/05, Tim Colson (tcolson) <[EMAIL PROTECTED]> wrote: > > in other words, the changes are backwards compatible, and the > > deprecation path is clearly set. there's no reason to wait for 2.0 > > before adding these enhancements. > Heh heh... ok, so I see now that the "fix version" is scheduled for 1.5 > ... but the first line in the issue -you- said 2.0. ;-)
context is key. the words "commons-logging" are very close to the words "wait until 2.0". :) > Seems you should comment (copy/paste the prev email) into the issue and > suggest the 1.5 fix schedule. already suggested 1.5 when i filed the wish issue, and you are as free to c/p my email in as i am. ;-) > Since this is a CORE issue, that scheduling should probably be the > responsibility of the dev responsible for actually releasing 1.5. That'd > be Will, right? close. people who open wish issues can request them to be in any version they like. the committers are free to overrule, of course. scheduling and or carrying out of the actual implementation/commit of the RFE/patch is the purvue of any committer who feels like it. the carrying out is the key part; the scheduling is a helpful formality. > So if folks support the patch for 1.5 and Will says this goes in 1.5... > it goes in 1.5, otherwise, it should be scheduled further out in the > roadmap. > > I know I'm being pedantic -- but I think this is the kind of process > that will help relationships with other non-commiters. They can see that > their patch was noticed, applied, tested, discussed, and (possibly) > scheduled due to enough support...and for when. > > > Timo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
