git merge is generally not too terrible at following file renames provided you do them in a single git commit so it recognises that something was renamed. However the package name changes (and thus the import statement changes) may mean that cherry picking or merging across branches requires a certain amount of manual fix up.
I guess the better question is "What is our support policy for Jena 2?" I assume that there would need to be a transitional period during which bug fixes go to both Jena 2 and 3 but in the longer term the intent would be to get everyone to migrate to Jena 3 and then stop supporting Jena 2. Since it would still exist as a branch people could choose to maintain it themselves once the project dropped support if they really couldn't migrate to Jena 2. If Jena 3 is primarily the package rename and RDF 1.1 on by default then I don't see any reason to use a Beta modifier. The essential code remains the same and is well tested and deployed so the Beta moniker seems inappropriate. I read your migration instructions and think they are pretty clear and concise. I hope that people won't have too many issues migrating forwards to Jena 3 (famous last words!). I suspect the biggest problem will be exactly the same as we see now, old code and tools out there referencing old versions of the libraries and creating class path conflicts when users (inadvertently or otherwise) end up mixing different library versions. I think ultimately our long term strategy has to be "Please move to Jena 3" because we won't have the bandwidth to maintain two parallel branches long term particularly once we start on some of the larger changes we've been musing about for Jena 3 (e.g. module reorgs). Ideally the more disruptive module reorgs should go into Jena 3 ASAP and be included in the first 3.0.0 release Rob On 24/01/2015 10:33, "Andy Seaborne" <a...@apache.org> wrote: >Here is a suggestion for Jena3. > >After 2.12.2 or 2.12.3, > >1/ A branch for Jena2 ; master is Jena3. >2/ Switch to RDF 1.1 setting for strings >3/ Rename com.hp.hpl.jena packages to org.apache.jena >4/ Other changes >5/ Let things settle down. >6/ Release (beta? just go for it as 3.0.0?) > >(3) is the disruptive step - I doubt git merge is going to be much help >after that for managing changes related to com.hp.hpl.jena packages > >I wrote some migration notes for the RDF 1.1 isms and packages. > >http://jena.staging.apache.org/documentation/migrate_jena2_jena3.html > >There is a lot of things that could be done. I like us to avoid >over-committing ourselves. The question I have is what is *necessary* >to drive into jena 3.first. > > Andy
