[EMAIL PROTECTED] schrieb:
Snipped where we agreed.
On 4/21/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] schrieb:
We should coordinate to convert all Collections to Generics.
+1 for internal use. In 2.1, we shouldn't change the API. In 3.0 we can
also change the API to use Generics.
Good point. Does our policy state a minor release should not remove
functions from the API. Do we even have a policy about major and
minor releases?
AFAIK there's no official policy. We should define one and state it in
the project guidelines (http://lenya.apache.org/docs/guidelines.html).
The only official versions are 1.2 and 2.0. 1.4 was
renamed 2.0 more from lack of an upgrade path than policy about the
API. Should moving to Java-1.5 wait until Lenya-3.0 so we can break
the API?
>
I have not tried mixing Generic and old-style container signatures.
Could we duplicate and deprecate in a minor release? Like:
Map<String> getSomething(){ ... return (Map<String>) map; }
/** @deprecated Please convert to Generics version **/
Map getSomething(){ return (Map) getSomething(); }
That might be a possible migration path. It sounds appealing to me, WDOT?
Eclipse complains about every non-Generic Container so this could be annoying.
1. A version of Lenya is designed for each version of Java. Anybody
requiring a specific version of Java for a CMS will not discard Lenya
because we do not have a gold version available.
I don't quite understand this - does this mean we should provide "flavors"
of each release which are tested with a specific Java version, or does it
mean that a release is designed for a specific Java version?
No, I was not suggesting maintaining multiple flavors. Today we state
Java 1.4 works. Java 1.5 and 1.6 usually work, but no guarantees.
Someone needing 1.4 can use any version through 2.0, and 2.0 will
likely be maintained into next year. A Java 1.5 version will break
1.4 compatibility. Most people will move to Java 1.5 because 1.4 is
EOL. The original suggestion jumped to 1.6. A built-on-Java-1.5
version would be good for people and companies not ready for Java-1.6
(and should work on Java 1.6 for people needing it.)
OK, thanks for clarifying!
3. SOP should upgrade dependencies when and only when creating
branches.
I'm not quite sure about this. What if there's a bug in a dependency? We
can't create a branch everytime this happens ...
-- Andreas
We discussed policies for dependencies a long time ago. Using only
gold versions of dependencies will reduce bugs. If someone wants new
features from another project, they can help that project create a
release. We should choose the versions when starting a point release,
then stick with the choices unless something is terribly broken (and
if so, downgrade to a known-good release rather than upgrade to a
hopefully-fixed more-recent version.) We had (and still have)
workaround code in the Lenya-1.2 branch because of a Cocoon bug that
was not fixed until Cocoon-2.1.11. If a new feature depends on a new
version of a dependency, push both changes (upgrading the dependency
and the new feature) to the next point release. RERO and this policy
will help much more than it hurts.
When Lenya-1.4 was started, Cocoon was at 2.1.7. How much of the
delay can be attributed to not staying with Cocoon-2.1.7?
I don't think that the continuous intregration was a major reason for
the delay. But maybe others have a different view of the situation?
(Does
Lenya-2.0 really depend on the Cocoon-2.1.x trunk? How can we
guarantee our code works when dependencies can change without our
knowledge?)
We can't - this is a reason why we waited until Cocoon 2.1.11 was
released before releasing Lenya 2.0. Preferring releases over SVN
revisions is IMO a good thing. But if a bug in a dependency occurs
during the development of a release, I'd rather try to upgrade to a
newer version of the dependency instead of going back to a previous version.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
