Outside pov: 1/ namings: I don't understand what is the jackrabbit-core and what is jackrabbit-jcr-commons, and a newbie would definitely look for jackrabbit distribution. Probably, I would understand the renaming jackrabbit-commons to jackrabbit-jcr-X. The other names are oke with me (ohh, just another one: why change textfilters to index-filters?)
2/ versioning: imo 1.0.4 is something that comes after a 1.0 version which is a major version. Moreover an 1.0.x is usually a bug fix for the 1.0version. But so far there was no 1.0 release. Moreover, I think the document discribing the versioning policy is very good and would give everybody the level of understanding needed. A project should be able to mark pre-release versions: like dev, beta, rc. Without this, everybody would consider that the distribution is a good/tested/validated releases that can be dropped in production. Unfortunately, I don't think this is true. hth, ./alex -- .w( the_mindstorm )p. On 3/29/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > > On Mar 28, 2006, at 1:13 PM, Jukka Zitting wrote: > > The Apache Jackrabbit 1.0 release candidate 3 can be found at: > > > > http://people.apache.org/~jukka/jackrabbit/1.0-rc3/ > > > > See the RELEASE-NOTES.txt for more details about the release contents. > > Hmm. This is getting a little hairy. > > 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). > > 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: > > * Jackrabbit content repository and general-purpose JCR utilities > > jackrabbit-core-1.0.3-src.jar > > jackrabbit-core-1.0.3.jar > jackrabbit-jcr-commons-1.0.3.jar > > * RMI network layer for the JCR API. > > jackrabbit-jcr-rmi-1.0.3-src.jar > jackrabbit-jcr-rmi-1.0-rc3.jar > > * WebDAV network layer for the JCR API. > > jackrabbit-jcr-webdav-1.0.3-src.jar > > jackrabbit-jcr-webdav-main-1.0.3.jar > jackrabbit-jcr-webdav-client-1.0.3.jar > jackrabbit-jcr-webdav-server-1.0.3.jar > jackrabbit-jcr-webdav-server-1.0.3.war > > * J2EE Connector Architecture (JCA) resource adapter for Jackrabbit. > > jackrabbit-jca-1.0.3-src.jar > jackrabbit-jca-1.0.3.rar > > * Text indexing filters for Jackrabbit. Includes example filters > for Adobe PDF and MS Excel, PowerPoint, and Word. > > jackrabbit-index-filters-1.0.3-src.jar > jackrabbit-index-filters-1.0.3.jar > > Should we be marking the non-core projects as alpha releases? > It seems very strange to me to be releasing software without > any documentation. > > > 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. > 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). > > OT: why does jcr-rmi have a dependency on commons-logging? > > ....Roy >
