Stefano Bagnara wrote:
I thought about moving these issues to 3.0 but IMHO they are
too critical to release 2.3.0 without them.
And this is part of why I keep thinking that we should call this release
3.0.
I'm still for 2.3.0 but I'm aware that this is a personal preference.
I'm not -1 for a 3.0 versioning scheme.
This latest changes are mostly bugfixes that should be invisibile to the
users: they need "critical" changes in the code but I think that the
version is a number for the users and not for developers and, as such, I
feel 2.3.0 better reflects this release.
As a user I would expect major changes when jumping from 2.x to 3.0,
maybe accompanied by introduction of new features and incompatible
changes in APIs and config files. As long as this is not the case I
would stick with 2.3 to stay in sync with expectations.
We have a few major steps beyond:
- remove javamail dependency from Mailet API / James?
- remove avalon dependency?
- change the repository interfaces?
I don't know wether we'll be able to implement one or more of them, but
even if we add just one of them then we would need a major version, so I
would avoid to start using only the first number of our product version :-)
About "tests" I felt free to commit the good starting work from Bernd
Given the volume of work we're getting from Bernd, I'd like to ask if he
would please submit a CLA. :-)
OK, no problem. :-)
>>And perhaps work towards Committer status.
:-)
Well, having others doing the review-and-commit-job for me is quite
convenient... ;-)
Stefano, thank you again for picking this stuff up.
Question: Should I create a new JIRA issue for every future patch or
keep attaching to existing issue JAMES-427?
It would be cool to have more people working on the sources!
I don't know much about but I remember that a few tests was already
present in the old "merger" branch. I'm not sure wether they can easily
ported to the current trunk or not, maybe Bernd would like to look at them:
http://svn.apache.org/repos/asf/james/server/tags/pre-v2and3-merger-trunk/tests/
Oh, I didn't know that. I'll have a look.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
