Hi, On 1/13/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > I think we should build a release candidate in incubator and then > vote on releasing the jars as 0.9.x. At that point, we should vote > on graduation and request a TLP from the board. > > Jukka, I encourage you to produce a few incubating release builds > as version 0.9.x as soon as you feel like that would be productive.
Sounds good. I'll set up a 0.9 milestone in Jira with the immediate stuff. With that I hope to have an initial 0.9 release ready during January. > We need to start working on the versioning rules and, since we are > a library, it will need to be clear that there will be no incompatible > interface changes in the 1.x series. We should run some tools on the > release package to be sure the public API is clean enough for use > by other projects. Good point. The main interface is of course the JSR 170 API, that I think we will be using for the entire 1.x series. I think that a good roadmap is to target Jackrabbit 2.0 as an implementation of JSR 283. This may cause a need to make a stable 1.x branch later this year to allow JSR 283 changes to be more easily introduced. I'm however not planning to make an immediate branch for 1.x as I think that at least 1.1 should come from the svn trunk. The other interfaces we need to stabilize are the main extension points like the PersistenceManager interface for external components and WorkspaceImpl.createWorkspace() for applications. Would it make sense to move such interfaces to something like o.a.j.api for clarity and for flexibility in modifying o.a.j.core? I've occasionally used japitools (http://www.kaffe.org/~stuart/japi/) for binary compatibility checking, perhaps we can start using that for Jackrabbit as well. Does anyone know of a Maven plugin for using japitools or other similar API checkers? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftmanship, JCR consulting, and Java development
