On 28/06/12 15:48, Simon Helsen wrote:
Andy,
s/Andy/Committers/ !
as a slightly off-topic question, has it been decided to only introduce
org.apache.jena packages in a back-ward compatible way? The last I read
on the topic, it seemed there was a back-and-forth on this, but nothing
fixed. I am asking because for us, an incompatible rename would be a
very difficult situation in terms of client adoptions
Jena has always emphasised compatibility - it's in the interests of most
if not all the project contributors as they use Jena as well as develop it.
We came to an consensus that the API will have a compatibility module
for com.hp.hpl.jena especially as this creates space for a new API,
similar to, but cleaned up from, the old API, to arise under o.a.jena.
But nothing is happening yet. It would seem to be helpful to have less
of com.hp.hpl.jena.*
For internal things, it's more of a case-by-case basis. If moving them
should at most catch people who have for some reason hooked directly
inside some implementation code, then it seems reasonable to me to cause
a degree of change, it's only package renames after all. Yes - that
means the client code needs to change; it's a balance. Too much
compatibility can be bad as well.
Andy
Simon
From: Andy Seaborne <[email protected]>
To: [email protected]
Date: 06/28/2012 09:32 AM
Subject: Re: Jena 2.7.2?
------------------------------------------------------------------------
On 21/06/12 23:34, Ian Dickinson wrote:
> On 21/06/12 23:23, Andy Seaborne wrote:
>> What do PMCers think? Do you have the energy to check another release?
> Do the right thing, not the expedient thing.
The "right thing" IMO is a release so we can get a stable cut and make
it easier to make further changes which might be best given time to bed
down (e.g. TDB commit optimizations). One that does require a bit of
space is sorting out RIOT, and the new reader stuff, putting it in core
and maybe renaming as org.apache.jena (need to make it a smooth
transition but I think that is leave SysRIOT as a stub).
Time to do a 2.7.2 build ...
Andy
>
>> (as it's a minimum of 3 +1's from the PMC that is needed for a release).
>>
>> Andy
>>
>> PS
>>
>> I was going to suggest jumping all the version numbers to be the same
>> sometime - e.g. 2.10.0 as being higher than all the modules as less
>> confusing.
> +1 to eventually sync'ing release numbers
>
>> 1/ Not sure we want to loose the ability to have single-module releases
>> just yet.
>> 2/ This is a bug fix release - a jump in minor version number seems
>> wrong.
> +1 to not on a bug-fix release
>
> Ian
>
>
