Hi,
On 3/29/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> We should be prefixing all of the files with jackrabbit-.
> I know that the jcr-* packages are usable with any JCR
> implementation, but the jackrabbit- prefix applies to everything
> produced in this project (not just the repository). Its a
> brand thing (and name collision avoidance as well).
That's reasonable. I'll go and change the names unless anyone objects.
While doing that I'd also like to change the svn paths to match the
project names. The svn trunk (and branches/1.0) would then look like
this:
jackrabbit-core
jackrabbit-index-filters
jackrabbit-jca
jackrabbit-jcr-rmi
jackrabbit-jcr-webdav
contrib
> Also, the package naming remains incoherent to me. I can't imagine
> what it would look like to a new user, especially since there is
> no documentation for the former contrib projects.
>
> Here is what I suggest for making the names coherent:
Looks good, I'll adopt that.
> Should we be marking the non-core projects as alpha releases?
> It seems very strange to me to be releasing software without
> any documentation.
I believe we should release those projects as they are pretty stable
and have a number of users judging from the number of mailing list
discussions and Jira issues. Having a released version makes it easier
to track down reported issues and also encourages users to stick with
a known good version. I also believe that more users will bring us
more documentation.
I'd also like to keep the version numbering in sync so that we don't
have separate release cycles for the non-core projects at least for
now. The best way to mark this status would IMHO be something like the
following added to the release notes:
This release contains the following modules in addition to the
Apache Jackrabbit
core. They contain extra functionality that can be used with
either Apache Jackrabbit
core or any JCR compliant content repository. These modules should
be considered
alpha quality.
> > There are no more pending 1.0 issues, so I'm hoping to start the 1.0
> > release vote based on this release candidate as soon as the JSR-170
> > conformance test results are in and given that no unexpected problems
> > have been reported.
>
> Right, here is another versioning issue then. We only vote to
> release complete and signed jar/tarballs. We can't actually have a
> vote on something called 1.0-rc3 because it wouldn't be a candidate
> if it gets approved, and we can't change the contents after it has
> been approved because then we would have to do all the testing again.
My intention with "based on this release candidate" was not to have
the release vote on 1.0-rc3, but that the only changes between 1.0-rc3
and 1.0 would be the version number change and other minor tweaks that
don't affect any of the functionality. The reasoning for this to make
the release vote smoother as the exact functionality has already been
tested by more than one person. I'm sorry for the misleading sentence.
> That is why we have three version numbers. Let's just stop using
> rcX and call the next set of jars 1.0.4. The first release doesn't
> have to end in 0 -- version numbers are free (and all versioned jars
> are release candidates).
-1 That would be very confusing in my mind. The -rcX suffix makes it
explicit that the package hasn't been officially approved as a
release. Otherwise someone with 1.0.3 and 1.0.4 packages has no clear
way to determine which one was officially released.
> OT: why does jcr-rmi have a dependency on commons-logging?
Hmm, good point. It was introduced a while ago in one of Felix's
contributions and I never really got worried about it as I always run
my RMI server from within Tomcat that has the commons-logging classes
already available. I'll remove that dependency.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development
