solprovider apache.org schrieb:
> Snipped where we agreed.
> On 4/21/08, Andreas Hartmann <andreasapache.org> wrote:
>> solproviderapache.org 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://l
enya.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: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org
|
