On 02/04/2008, Matt Benson <[EMAIL PROTECTED]> wrote: > > --- Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > On Wed, Apr 2, 2008 at 3:51 AM, Matt Benson > > <[EMAIL PROTECTED]> wrote: > > > > > > --- James Carman <[EMAIL PROTECTED]> > > wrote: > > > > > > > On Tue, Apr 1, 2008 at 5:30 PM, Matt Benson > > > > <[EMAIL PROTECTED]> wrote: > > > > > Good questions! I suppose that's the thing > > to > > > > do, > > > > > with the understanding that my pushing this > > makes > > > > me > > > > > liable if I don't get off my ass and do > > what's > > > > needed > > > > > to get that branch releasable, huh? > > > > > > > > > > > > > So, how will this work if we want to promote > > this > > > > thing to the proper? > > > > > > To be honest, I'm not sure why [functor] was > > never > > > ready to graduate, but I intend to get a better > > idea > > > of its true status during the next week or so... > > > > > > > > > > Do we promote based on the 1.0 code? > > > > > > If for some reason the generics branch is ready > > before > > > the 1.0, perhaps we can cross that bridge when we > > come > > > to it? > > > > > > > > > > We can't do a > > > > release out of > > > > the sandbox, correct? > > > > > > Correct. > > > > > > > > > > Or, does it even matter that > > > > we'll have two > > > > active branches (trunk and the non-genericized > > 1.0 > > > > branch) before > > > > promotion? > > > > > > I don't see that it really matters. :) > > > > I can't help thinking it would be better to just > > work on one copy > > initially (i.e. trunk) - review whats there and do > > as much work as > > possible before doing the generics stuff. Otherwise > > you're just going > > to be duplicating each other. I just noticed Matt > > added checkstyle > > rules to the branch - thats a good example of > > something that would be > > good to sort out only once. > > > +1
> I've actually been thinking the same thing--if we get > other issues sorted out before adding generics code. > I'm just trying to keep my personal desire for a > 1.3-compatible release from infringing too much on > others who may not want it. I actually don't have > much to gain from such a release, but a) you never > know what you'll need tomorrow/next week/year, and b) > I've yet to find anything in the codebase that says > IMMATURE! to me, so I don't see why we can't resolve > any issues fairly quickly. If we're that close to > being able to provide a working implementation, why > shouldn't we? > +1 I've run Findbugs and there aren't any serious errors - it reports non-transient non-serializable fields in some classes, but they are for interfaces for which users are advised to create serializable implementations. These can be fixed in a Findbugs exception filter. Eclipse builds everything using 1.3. However, it's currently difficult to build/test against 1.3 from the command-line, as there are no Maven 1 or Ant build files. Anyone care to add either? > -Matt > > > > Niall > > > > > > This is somewhat of a weird situation. > > > > > > > Agreed. :) I specialize in those. > > > > > > -Matt > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > ____________________________________________________________________________________ > You rock. That's why Blockbuster's offering you one month of Blockbuster > Total Access, No Cost. > http://tc.deals.yahoo.com/tc/blockbuster/text5.com > > --------------------------------------------------------------------- > > 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]
