On 4/9/06, Jason Dwyer <Jason.Dwye..edata.com.au> wrote:
>
> IMHO, given that the 1.2 line has been in the works for some time, and
> any effort to repackage the class tree will almost certainly lead to
> changes ( trivial bug fixes, etc), why not stick to the org.objectstyle
> packaging for the 1.2 final release, and move on ot org.apache from
> there?
>
> another consideration in the naming scheme is to align the version to
> specific java specs. ie: release 1.5 corresponds to ( and provides an
> implementation compatible with) java 1.5.
>
>
Well just to be clear, nobody is talking about doing a dual version. While I
did suggest 1.2-apache, I was quickly and rightly talked out of it :)
What is proposed is to make a release that is API-"equivalent", but with a
new package structure. Development on a new release would begin immediately
thereafter on a version that is not API-equivalent or API-compatible. The
idea is that we provide an upgrade path. If the org.apache release becomes "
2.0", a hypothetical "3.0" release is going to be a long way off. A
1.2->3.0upgrade would be difficult for users, because of new package
names AND new
class/method names. A 1.2->2.0->3.0 upgrade would allow users a more
controlled upgrade path should they choose to take it.
By the way, I disagree with the idea of versioning along side the JDK. That
may make sense for aspect-related stuff, etc, but I don't see Cayenne going
"1.5 only" anytime soon, and even if it were to, I don't see it going
"Mustang-only" ever, since Mustang has few API changes that would be worth
breaking backward compatibility over.
Cris
This archive was generated by hypermail 2.0.0 : Sun Apr 09 2006 - 17:58:44 EDT