On Tue, Dec 13, 2011 at 8:22 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
> Lots of applications depend on the 1.x branch as it is now. Hello, What does it mean for an app to depend on a specific branch in SVN? Do those apps depend on 1.x SNAPSHOT releases? Do they download the code and compile it? Which is where moving to J1.5 be a problem? How can such a thing even be supported? > We really can't just drop support. I am not asking to drop support. Anyone one can do as they please to support whatever version they want. If I want to stay on J1.3 and fix the P1.5.x line, I can do so. Generics is the natural evolution of the P1.x line from P1.5 to a P1.6. I'm not interested in J1.3, so I'm not going to support it. I am interested in generics now, so I am supporting it now. If there were no P1.6, then yes, I'd fix P1.5 because that would be the only game in town. > At least we shouldnt, IMO. What you are proposing is a third release > line. There is no need for a third release line until someone needs it and does the work. If I am stuck on pre-J1.5 and I want a 1.5.x, I create that release, if that means I have to create a branch, then that's what I have to do to support an obsolete J1.3 platform. > As I have stated before, we are having a hard time getting timely bug fix > releases out now with just *one* release line. Are you prepared to > support the code fully? Are there other volunteers willing to step up to > diagnose and fix bugs in two versions of the 1.x branch? > Right now, I'm doing the best I can do for [pool1] and generics. I'll support the code the same way I support any Commons code, when I take the time to do so. If P1.6 is as simple as /only/ adding generics, then I predict we'll see a good adoption rate. Gary > > Phil > > > > On Dec 13, 2011, at 6:11 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > > On Tue, Dec 13, 2011 at 7:01 AM, sebb <seb...@gmail.com> wrote: > > > >> On 13 December 2011 11:36, Simone Tripodi <simonetrip...@apache.org> > >> wrote: > >>>> > >>>> Generics would help to ensure suitable types were being used, but> > >> would do nothing to prevent the subtle threading bugs that misusing a> > >> protected field can cause.>> To my mind, it would paper over a few > cracks, > >> whilst leaving gaping> holes elsewhere.> > >>> we just voted a new maintenance release for [pool] that brings exactly > >>> the same bugs, what should prevent us cutting a new release adding > >>> something comfortable for our users - and some of us, included myself > >>> - such as generics? > >>> > >>>> Unfortunately, because the original code was created with exposed> > >> mutable data items, it's just not possible to fix it without breaking> > >> binary compatibility. > >>> > >>> agreed, maybe I got Gary wrong but IIUC the purpose for a 1.6 release > >>> is just providing Generics... or not? > >>> 2.0 provides a lot more - not only locks are fixed, but internals are > >>> more performant - so I don't see issues having 1.6 released. > >> > >> But what is the point? > >> > > > > The point is I really want an easy path to generics now, with as much > > compatibility as possible, including 1.5 warts and all. > > I want to clean up my [pool] call sites ASAP. It's one of the rare key > > spots in my app that does not support generics. > > We have all this nice generified code except when hitting the [pool] > edges, > > that's ugly, unsafe, and unnecessary. > > I also do not want the risks that come with a whole new [pool2] impl. > > > > Do generics really make enough difference to be worth spending the time > on? > >> > > > > I started this thread for a reason :) > > > > > >> > >> Note also that Pool 1.x currently targets 1.3, so adding generics will > >> force source compliance of at least 1.5. > >> > > > > Well, yes, that's not a surprise, compiling generics requires J1.5. > > If someone cares to maintain a Java 1.3-compliant branch, be my guest. > > > > > >> Not sure if it will force target compliance of 1.5 as well. If so, it > >> > > might no longer be a drop-in replacement for some isers. > >> > > > > True, and worse for compilation, if you do very odd things with pools, > your > > call sites might not compile. But that would be true of any new lib that > > adds generics. Once you declare a pool with a type, you can't just shove > > any old Object in there anymore. > > > > My proposed plan is to migrate the 1.x branch to generics (done on my > > machine, like Simo, it's not the first time its been done ;) > > > > If someone want to release a 1.5.x release after 1.6, create a 1.5.x > branch > > from the last 1.5.x tag. Doing another 1.5.x would mean that person want > > J1.3 compatibility, and does not care for J1.5. > > > > At work, we have been on J1.6 for years and are now experimenting with > > J1.7. I know some people like in a pre-J1.6 world, and no one is forcing > > anyone to upgrade. I do not care to rehash the 'when is it OK to use Java > > 5-6' debate. > > > > As I mentioned, [pool2] can cook all it needs until it is fully baked as > > far as I am concerned. If this causes people to rekindle their [pool2] > > efforts, then I'm happy this provided the catalyst. > > > > Gary > > > > > > > >>> My 0.02 cents, > >>> -Simo > >>> > >>> http://people.apache.org/~simonetripodi/ > >>> http://simonetripodi.livejournal.com/ > >>> http://twitter.com/simonetripodi > >>> http://www.99soft.org/ > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > -- > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
