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? 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(); }
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.)
> > 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? (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?)
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
