+1 from me, sounds like a good plan. You would not want to do the dual branches in svn! On 9 Sep 2014 12:50, "Andy Seaborne" <[email protected]> wrote:
> Claude +1'ed and I'm OK with this plan. > > Is everyone else OK with it? (please "+1/0/-1") > > If so, I'll call a VOTE for moving trunk. > > It'll look like: > > https://github.com/apache/jena > > The website remains in subversion because the CMS/svnpubsub does not as > far as I know, work with git. > > As for the misc items we have (Experimental/, Imports/, Scratch/ etc), I > suggest we leave them for now to keep the main migration clean, then > migrate them separately if there is a requirement. > > Andy > > On 03/09/14 11:47, Andy Seaborne wrote: > >> I had a go at refactoring to have both org.apache.jena and >> com.hp.hpl.jena APIs (my target was the RDF and ontology APIs). It >> looks possible but isn't trivial. Some classes link the API to the SPI >> and that then gets a bit messy, which equates to it's not a perfect drop >> in replacement. >> >> But I also got to ask myself about whether this really is an advantage >> to users and the project. >> >> A/ If there is a legacy, when will it go away? >> >> B/ If there are multiple classes called "Model", it can be quite >> confusing for people. Autocomplete is already polluted enough. >> >> C/ There isn't one system to use because using Jena involves choosing >> different setups via jars included, which in itself may cause a steady >> stream of questions. >> >> And with changes like RDF 1.1 persistent data, there are changes anyway >> that a major version change reflects. >> So ... >> > > 1/ Move the code to git > 2/ Repackage com.hp.hpl.jena -> org.apache.jena > 3/ Declare jena-3.0-alpha-1 (not a release - just POM version set.). > 4/ Starting making changes > (like RDF 1.1 details - invalidates persistent data). > ... > X/ Release jena-3.0.0 (when we feel it is ready). > >> So just making the package rename once and for all seems to me to be >> just as helpful. It's a bump at the point of jena2 -> jena3 but the >> bump is going to happen if the legacy adapter ever goes away. >> >> A quick migration route for user code is to convert all the imports: >> >> s/import \s+com.hp.hpl.jena/import org.apache.jena/g >> >> in your favorite editor (including Eclipse). >> >> Obviously, some corner cases, like full names for classes, do not work >> but I think they will be few and far between. >> >> Whatever we do, we end up with parallel codebases to apply bug fixes to. >> The only practical way round that that I can see is to delay making the >> package rename as late as possible. That does not seem very attractive. >> >> Data namespaces are untouched. We can consider them separately, on a >> case-by-case basis. >> >> So ... >> >> 1/ Move the code to git >> 2/ Repackage com.hp.hpl.jena -> org.apache.jena >> 3/ Declare jena-3.0-alpha-1 (not a release - just POM version set.). >> 4/ Starting making changes >> (like RDF 1.1 details - invalidates persistent data). >> ... >> X/ Release jena-3.0.0 (when we feel it is ready). >> >> Andy >> > >
