jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: 1.0 release plan (Was: time for another incubator board report)
Date Sun, 15 Jan 2006 20:26:13 GMT
On Jan 15, 2006, at 4:09 AM, Jukka Zitting wrote:
> On 1/13/06, Roy T. Fielding <fielding@gbiv.com> wrote:
>> 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.

Okay, but you can also just use the 1.0 milestone -- we all know
that is the real destination anyway.  0.9.x is just practice so that,
when we build 1.0, we have all the kinks out of the release process.

>> 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.

Yes, though I actually meant that we need to document what the versions
mean so that we all agree.  For example


> 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?

Yes, I think Toby has wanted to do that for a long time.

> 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.

Cool, didn't know about that one.

> Does anyone know of a Maven plugin for using
> japitools or other similar API checkers?

I searched but didn't find one.


View raw message