incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Helsen <>
Subject Re: Fwd: [DISCUSS] - Packages renaming and backward compatibility
Date Wed, 29 Feb 2012 14:24:22 GMT
hi guys,

I can tell you that changing package names would be a *major* problem for 
us because we re-expose Jena as a library to our own clients (which are 
internal, yes, but in IBM that is as good as external). This level of 
required adoption would become a massive burden for these clients and 
therefore make it more difficult to upgrade. Note that right now we are 
still on Jena 2.6.3/tdb 2.8.7, but for our 2013 product release, I would 
like to upgrade to the first complete apache release of Jena (including 
all components) and take up all the goodies that have been introduced 

Of course, we know that ultimately, you'll want to make the package 
change, but it would help a lot if you create a dedicated separate release 
with *just* the package renaming. So, the proposal would be to release 
with old packages first and then create a version with the new packages 
which you immediately release again with a higher number (by "immediate", 
I mean without any feature, API or even bug changes). This allows adopters 
at least initially to choose if they want to take the cost and they then 
know that after that they will have to deal with it one way or another.

As a side note, but somewhat related: One of the problems we have had with 
Jena in the past is undocumented public API changes. In general, we 
understand that APIs change, but solid libraries have a) a deprecation 
strategy and b) at least a release note of every single API change and an 
explanation as to why or the alternative. 

just my 2ct 


Ross Gardler <>
02/29/2012 09:12 AM
Re: Fwd: [DISCUSS] - Packages renaming and backward compatibility

On 29 February 2012 13:51, Benson Margulies <> wrote:
> One person on general@ has got this idea in his head about renaming,
> and a board member and a host of others have told him, 'no'. So
> there's no cause for concern.

+1 (although Greg is not speaking as a board member - he simply said a
change of policy would require a board resolution, if one were
submitted then he would speak as a board member after discussing with
the whole board)

Jena is OK, it's a storm in a teacup. Your mentors will intervene if
necessary (as Benson just did here). For now monitoring the thread and
providing appropriate support to the "correct" course of action is all
you need to do right now.


> On Wed, Feb 29, 2012 at 8:40 AM, Andy Seaborne <> wrote:
>> On 29/02/12 13:13, Ian Dickinson wrote:
>>> On 29/02/12 12:05, Andy Seaborne wrote:
>>>> A discussion on general@i
>>>> It will resolve whether we have to repackage Jena to graduate.
>>> It's not just the repackaging. Some of the more astringent commenters
>>> are "shocked" that even having compatibility packages and classes (i.e
>>> not under org.apache) in a TLP has ever been allowed. So depending on
>>> how the vote goes, we could be forced to remove all mention of 
>>> from the code base, and host the compatibility layer packages 
>>> else.
>>> The problem that gives us is that all the references out there to Jena 
>>> code samples, presentations, articles, papers, tutorials and even 
>>> will be instantly out of date. The discussion on general@ has the 
>>> of "well, it's Cloudera's problem so let them sort it out" but that's
>>> not true for Jena. It's not HP's problem!
>> Absolutely agree.  And to your general@i email.
>> It's a major cost to users, and I don't see that it is to anyone's 
>> to force the extreme case of no non-apache packages.
>> It's hard to determine but I don't see any evidence that some set of
>> potential users is put off using Jena by the package name.  We do known 
>> leaving HP made a difference.
>>> If we have to re-name packages to graduate, so be it that's not really 
>>> big deal**. If we have to completely expunge all mention of com.hp.*,
>>> that would be at the very least disappointing.
>> And then there are vocabularies :-|
>>> Ian
>>> ** Well, it'll take some work to get the site docs and Javadoc in line
>>> with the packages.
>> The other thing about this whole discussion is that it is loaded.
>> If incubator expects a project to rename, it's still not promising it 
>> graduate.  So a podling comes in, does the change, gets mauled, the 
>> community messed about.  Can the podling take the namespace with it if 
it is
>> retired?
>>        Andy

Ross Gardler (@rgardler)
Programme Leader (Open Development)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message