> With all of the changes we are apparently planning to put in > this release, and particularly we are now talking about > dropping support for JDK 1.3, perhaps we should call this version 3?
The next release incompatibilities: - minor configuration changes (datasources=>datasource, and few others) - minor MailetAPI changes (but they need recompilation of the mailets) - avalon 4.0=>4.1 (component=>service) upgrade (again mostly recompilation, minor source changes). - dropped jdk1.3, require jdk1.4 The following one: - major MailetAPI changes - Container switch (OSGi, Spring, J2EE...) - Major configuration changes (due mainly to container switch) - storage/data incompatibility (we need to refactor repositories). We for sure need a major version switch between the 2 release so (as I said before) we can name them 3.0.0 and 4.0.0 or name them 2.3.0 and 3.0.0. I would prefer the 2.3.0/3.0.0 choice because: - there are no major changes in current trunk: we mostly fixed bugs, added minor features, upgraded the dependencies - the switch from 2.2.0 to the next (2.3.0) will be really easy: just update the config, replace component with service and rebuild your mailets and upgrade - if you don't use custom mailets you just need to chage few lines in the config.xml and start the new james. - the storage is IDENTICAL to the previous version and you can also switch back to 2.2.0 anytime. BTW I would go for a 3.0.0/4.0.0 scheme if we plan to introduce more interim releases (3.1.0, 3.2.0..). I searched the james site/docs and i found no "versioning rules" so we can simply vote it, or better the PMC can choose. We probably need a single vote to: - choose to drop java 1.3 - choose wether to ship without bcprov and let the user download it from bc site - choose the release name (2.3.0 / 3.0.0) - choose wether to remove mm.mysql from the sources - choose wether to enable file repositories or derby by default The first 2 questions are blocker for the release. As we are in August and many james committer seems to be on holiday we could go with the votes we get and eventually change the plans if any committer/pmc complain for the changes. > > I would like to do an alpha release as soon as possible (20 > august?) > > Who can do a release? How does it work? > > We can't until we address BXA. Once we do, I can handle the > release. I've got the build and signing scripts, plus, my > key is in the ASF WoT. I will do the tests to know what we should require to distribute james without crypto code so we can move! Will you go on holiday in the next weeks? (We should plan the release in a week you "are able"/"have time" to do the release :-) ) Stefano PS: Noel, can you fix the gump issue I referred previously? (replace "dnsjava-1.6.2.jar" with "dnsjava-2.0.0.jar" in https://svn.apache.org/repos/asf/gump/metadata/project/james-server.xml ) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
