Danny Angus ha scritto:
On Jan 23, 2008 12:13 AM, Steve Brewin <[EMAIL PROTECTED]> wrote:
Would it be possible to further classify Stefano's excellent list of new
functionality in trunk to indicate which rely on none, minor or major API and
schema changes? Then we could evaluate what is the 'low hanging fruit' that we
could most easily harvest for an initial milestone drop.
Sounds like a good idea, I'll give it a go.
d.
Sorry but most of that features has been written 13-24 months ago and my
memory is very limited. I don't know if Norman has better memory of the
specific changes.
For what I remember the FIRST task has been to refactor services
interfaces to accomodate new features and then we started adding new
features. Most of the features we didn't include in 2.3 was delayed
because they required critical API changes, so I guess most of the
features we kept in trunk for so long are there because they required
API changes.
I'm not sure about "schema changes": if you mean the db schema, then
IIRC there are no changes required on the db. Excluding the *new* IMAP
code and its backend libraries (mailbox manager) the rest of the code
SHOULD be storage and config.xml backward compatible with the v2.3 branch.
I won't go in the svn logs to understand what changes each feature
required, I have not enough time for a similar task. If anyone is
willing to do this then I can tell that I tried to use JIRA-XXX labels
in most commits (not every, sorry) and to have a JIRA issue for each
feature I worked on, so starting from JIRAs and their "Subversion
Commits" pages could help.
Many new service interfaces have been introduced to increase the
granularity of the components. Many interfaces have been simplified or
changed to better define services responsibilities/contracts. Many
"hardcoded" behaviors have been extracted to components and coupled via
service interfaces.
I think that looking back is only a waste of time. We already waited an
year, let's look forward and let's consolidate what we have instead of
trying to extract parts of what we have for a partial goal.
My only concern wrt non-imap code is the handlerapi/smtpserver code. We
have an handlerapi version in v2.3, one different api in trunk and a
couple of experiment in sandboxes. Unfortunately I think that none of
that api can be considered final and not experimental. For a milestone I
would go with trunk, if instead an early release is planned I would
suggest to go back to the v2.3 api, so to not break that api
compatibility for the minor changes introduced in trunk. If instead
someone will show his interest in revamping some of the experiments in
the sandboxes then we could evaluate a bigger jump (to be realistic we
should plan a task in the roadmap only if we have someone willing to
work on that task, otherwise try to make a roadmap without that task, if
it is not mandatory).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
