Internal generics work can occur at any point. API changes should be minimized, but if they're mostly backward compatible-ish, I don't see them being a big deal. If anything, I'd rather start getting some user feedback before we go too far down the wrong path. Likewise, I think some degree of breakage is acceptable between milestones.
As for @Override, that's fine with me. I like them better as a bug catcher than as something informative. Most IDEs will show overridden methods, but if you make a typo in a method signature, it's hard to tell whether or not it should be overriding something. The annotation essentially gets rid of that whole class of problems, so +1 from me. -- Kevin On 1/12/08 3:30 PM, "Aristedes Maniatis" <[EMAIL PROTECTED]> wrote: > > On 12/01/2008, at 5:29 AM, Kevin Menard wrote: > >> What is the release plan for 3.0 M3 then? I'd imagine we'de want to >> square >> away any remaining API changes related to the Java 5 conversion (at >> least as >> well as we can). Are there any other blocking issues? > > There's still a bit of generics to pin down if we want to finish all > that before M3. Interestingly I notice a similar parallel discussion > on the WebObjects list at the moment with regard to generics in > EOFetchSpecification. > > Of course there can be as many milestones as we want, but I think the > Java 5 change is a long way from being completed. > > Anyone have objections to me adding @override tags? I find them quite > useful. > > Ari > > > > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > >
