Committers, if the API is internal, it is fair game for renames. I understand that. Now, when I ask for backward compatibility, I am talking about things which are obviously public like the Model API which is used a lot and I believe is not internal. If there is a compatibility mechanism, we should be good.
This leads to another question: what is internal and what is not? I ask because we were currently exposing everything to our clients and of course, there is always someone who will use something low-level or exotic. In fact, while moving to 2.7.1, we had a client in that situation. Fortunately, there were able to move away from this non-API, but I had hard time explaining what was public and what was not. I guess my question is also a proposal: if you start restructuring things, perhaps it would be nice to insert a clear boundary of what is public and what is private. For instance, all public APIs (of each component) could go into a separate sub-component? Then only changes in the former would need to be documented in a release (in a readme or whatever means practical). You could start very conservatively, i.e. very little is public, and gradually you push things in there which you expect clients to develop against Simon From: Andy Seaborne <[email protected]> To: Simon Helsen/Toronto/IBM@IBMCA Cc: [email protected] Date: 06/28/2012 11:25 AM Subject: Re: Jena 2.7.2? 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 > > > > > > > >
