Noel J. Bergman wrote:
Steve Brewin wrote:
Norman wrote:
Vincenzo Gianferrari Pini wrote:
On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I've added this point because Noel and Vincenzo brought
this as animportant point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reporting what I understood was important (and feasible)
to the PMC.
We just stressed the fact that life must be kept as much
as possible easy for users when upgrading to new release,
otherwise they may stay behind. Regarding configurations,
this goal can be achieved either keeping as much as possible
backward compatibility for existing features, either providing
(safe and thoroughly tested) conversion tools. But we have to
be aware that slowly adding small configuration
incompatibilities can sum up to require complex conversion
tools, that nobody would develop and would become a bottleneck
when releasing a new version.
Thats right but with no new features we will loose users and not get
new.
We have never said NO NEW FEATURES. STOP SPREADING A FALSE MEME!
For JAMES v2.4, the changes should be compatible. For JAMES v3, they can be
incompatible. We all agreed on that when we met at ApacheCon. And we can
deliver both in parallel. I would expect most work from most of us to focus
on JAMES v3, and if we don't want to backport something, then it doesn't get
backported.
Just to let everyone know that I was not at ApacheCon and I never agreed
on this.
In detail I don't agree on version numbers, and to overcome this problem
I started talking about next-minor (what Noel calls v2.4), next-major
(being defined 2.4, 2.5 or 3.0 by different authors), next-greater (what
Noel calls v3).
I agreed that we can deliver "next-minor" and "next-major" in parallel,
never agreed on a "v3 incompatible" to be released in parallel. I
defined "next-major" as compatible (whatever number we'll assign to it).
I think we just need to document what to change in config.xml.
Not good enough. That doesn't address that overtime, these incremental
changes could add up to a lot of require changes to migrate.
I already gave a lot of importance of your (you, Vincenzo, and others)
concerns about config.xml changes and I'm working with Norman to make
sure trunk we'll start also using a config.xml from 2.3.0 (but not the
reverse thing).
We everytime keep this in mind when working on trunk. Some minor
backward incompatibilities can't be avoided and are needed because we
have to fix bugs or bad behaviours previously present in James.
See for example the "ignoreCase" issues I described and I started fixing
in trunk. James 2.3.0 and previous had a WEIRD behaviour wrt ignoreCase
and as an example behaviour was different between files and jdbc
repositories. Trunk will support the same configuration with the same
syntax but will fix this differences (so in some scenario it will work
slightly different).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
