On Nov 17, 2009, at 8:40 PM, Niclas Hedhman wrote: > On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz > <jus...@erenkrantz.com> wrote: > >> As Hyrum suggests, we can use org.apache.subversion.* if we want to >> create a new (better) Java interface within our versioning rules - but >> that isn't necessary nor should it be a pre-req for graduation. > > IMNSHO, either Subversion address this issue pre-graduation, OR we > remove the package name change requirement for ALL incubating > projects, leaving it up to the project post-graduation to address it. > It has been a contentious issue in the past, and will be so in the > future, and I am not going to defend ASF's position if it doesn't > apply to everyone. > > I would actually like to hear from more Java-centric developers of > Board and IPMC what they think about this...
I've already weighed in, but here is my answer again. I have mixed feelings, as I suspect the folks who asked this question in the first place do. Our package naming requirements aren't really out of the norm. But to expect the subversion project to break backward compatibility just to graduate is a bit much. That would be like redhat insisting that all the JBoss packages be renamed from org.jboss to org.redhat. There has to be a middle ground that is acceptable and won't cause chaos with the project's customers. One solution that was mentioned was to do the rename but allow a compatibility jar with the old names. Another solution was to create a jar with the new names that refers to the existing jar. Presumably all new functionality would go there. I'm even OK with leaving as it is and creating a new jar with correct package names for new functionality and just having a concrete plan on how to do it. To me, any of these is acceptable. What I'm personally not OK with is leaving it as it is for years unless tigris.org is owned by Apache, which I'm pretty sure isn't going to happen. Ralph
