[I renamed the discussion thread to separate it from the vote thread.]
I agree with Michael that the first and most obvious benefit is
merging cayenne-jdk1.4-unpublished and cayenne-jdk1.5-unpublished in
a single module and getting rid of 1.4 workspace.
Separate from that, IIRC Ari have already voiced concerns about 3.0-
final being too far in the future. Why would that be a problem? We
are releasing high quality milestones that people can use in
production, but beyond that I feel like we don't have "completeness"
of the new feature set that would warrant a final release. I am open
to discussion on that, but so far I don't see a reason to rush.
Andrus
On Aug 14, 2007, at 8:39 AM, Michael Gentry wrote:
> "Will moving to JDK 5 be a change in label only, or will we actually
> go in and implement generics throughout all the classes, possibly
> requiring some API changes along the way to do it right?"
>
> I'm thinking it'll be a label-change only (well, except the JPA stuff
> does indeed require Java 5), but would allow us to start integrating
> Java 5 features into the main code baseline (which would make Cayenne
> 3.0 incompatible with Java 1.4). I don't imagine any of us are
> wanting to go refactor working code at the moment, but we can do ad
> hoc changes as parts of the code are being worked on.
>
> "Will this then add 3-6 months to the release of 3.0..."
>
> Right now, Cayenne is broken into 2 Eclipse projects -- one for Java
> 1.4 and one for Java 1.5. To do development between the two, you
> should switch Eclipse workspaces (or run Eclipse twice), which is a
> pain. And I did mean switch workspaces, not switch projects. I would
> think having the entire Cayenne 3.0 release codified under a single
> Eclipse project would simplify and improve the development effort, not
> cause real delays.
>
> /dev/mrg
>
> PS. I'm +1 for Cayenne 3.0 to require Java 1.5.
>
>
> On 8/13/07, Aristedes Maniatis <ar..aniatis.org> wrote:
>>
>> On 14/08/2007, at 4:11 AM, Kevin Menard wrote:
>>
>>> Since this is a bit of a big change for us, and Ari had expressed
>>> some
>>> concern, I'd like to just take a vote to ensure this is the
>>> direction we are
>>> heading.
>>
>> I certainly see the benefit in the longer term, but I wonder what the
>> purpose of this change is right now half way through the 3.0
>> development process. Personally I'd like to see 3.0 out as soon as
>> possible, since it has been a long time since the last stable new
>> feature release (1.2) and I think releases help keep up the perceived
>> momentum of the project.
>>
>> Is the plan for 3.0 to not release until it has full JPA compliance?
>> If so, a release this year seems unlikely.
>>
>> Will moving to JDK 5 be a change in label only, or will we actually
>> go in and implement generics throughout all the classes, possibly
>> requiring some API changes along the way to do it right? Will this
>> then add 3-6 months to the release of 3.0 while the changes are
>> ironed out? Are there other JDK 5 features we desperately want to
>> use? I know that the Swing improvements could make the modeler nicer,
>> but that too requires a whole bunch of work. I've just done a lot of
>> work putting generics into my major project, and it isn't always as
>> simple as pressing the 'add generics to this class...' button in
>> Eclipse.
>>
>> * generics
>> * swing improvements
>> * nicer for loop (but very minor functional change or speed
>> improvement)
>> * other little things
>>
>> So my hesitation is to do with feature creep. If moving to 1.5 adds
>> to the release schedule considerably, then I'm -1.
>>
>>
>> Sorry to sidetrack this vote with questions, but I'd like to be clear
>> about the benefits/costs of this decision.
>>
>>
>> Ari Maniatis
>>
>>
>> -------------------------->
>> Aristedes Maniatis
>> phone +61 2 9660 9700
>> PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
This archive was generated by hypermail 2.0.0 : Tue Aug 14 2007 - 09:57:00 EDT