incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Vesse <>
Subject Re: [DISCUSS] - Packages renaming and backward compatibility
Date Wed, 29 Feb 2012 21:38:36 GMT
On Feb 29, 2012, at 6:24 AM, Simon Helsen wrote:

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

Should we have to do the package rename at some point in the future I like Simon's suggestion
of the package refactor only release.  As he points out it gets improvements and bug fixes
into the hands of users without breaking compatibility and potentially gives them an easier
path to move to the new strategy because they can potentially migrate to the new apache branded
packages just by doing a find and replace on their code


> 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 
> Simon
> From:
> Ross Gardler <>
> To:
> Date:
> 02/29/2012 09:12 AM
> Subject:
> 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.
> Ross
>> 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 
> com.hp.*
>>>> from the code base, and host the compatibility layer packages 
> somewhere
>>>> else.
>>>> The problem that gives us is that all the references out there to Jena 
> -
>>>> code samples, presentations, articles, papers, tutorials and even 
> books
>>>> will be instantly out of date. The discussion on general@ has the 
> tenor
>>>> 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 
> benefit
>>> 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 
> that
>>> leaving HP made a difference.
>>>> If we have to re-name packages to graduate, so be it that's not really 
> a
>>>> 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 
> will
>>> graduate.  So a podling comes in, does the change, gets mauled, the 
> user
>>> community messed about.  Can the podling take the namespace with it if 
> it is
>>> retired?
>>>       Andy
> -- 
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective

View raw message