Sounds like a plan, I don't have any strong preference on time scales Other comments inline:
On 21/04/2015 09:28, "Andy Seaborne" <[email protected]> wrote: >Jena 2.13.0 has been out for out for a few weeks now and nothing too bad >has happened (yet ... :-). > >So let's start Jena3! > >Summary: >Please +1 if the process and timescale below works for you. > >(If I don't hear to the contrary I'll start the process later this week.) > >------------------------------- > >Knowing there is some in-progress changes in various places, I wanted to >confirm with everyone that now is good time, especially JENA-380. > >If the timescale is inconvenient, do say so now. >The timescale isn't driven by external needs so it's flexible. > > >Proposed detailed process for the first steps. > >A/ Tag master with "jena-2-3-split" > >B/ Create remote branch jena3 > Create remote branch jena2 > >Branch "jena3" is short-term, just to get the first steps sorted out and >reviewed, i.e. preparation for (1). It quickly becomes "master". > >C/ Do step 3 : Rename com.hp.hpl.jena packages to org.apache.jena > >That is, package trees: > >jena-sdb/src/test/java/com/hp/hpl/jena >jena-sdb/src/main/java/com/hp/hpl/jena >jena-core/src/test/java/com/hp/hpl/jena >jena-core/src/main/java/com/hp/hpl/jena >jena-arq/src/test/java/com/hp/hpl/jena >jena-arq/src/main/java/com/hp/hpl/jena >jena-tdb/src/test/java/com/hp/hpl/jena >jena-tdb/src/main/java/com/hp/hpl/jena > > >I've just trialled this for the codebase and it is scarily easy to do >with Eclipse. Yep tis nice isn't it, I presume you have a version of Eclipse with proper Git integration or you do the appropriate Git invocations so Git registers these as file renames in so far as is possible? > > >D/ Get the build working. > >Lots of POM updates to do but I have a build that builds. > >(this isn't everything - it leaves scripts, logging settings and >resources to be done) > >E/ Check and review > >Is 24 hours enough here? >I want to keep the window between (C) and (F) small to cope with changes >during that window. > >F/ When confirmed: > > merge jena3 into master and push > >If the merge does not work, delete master, and rename jena3 to master. Provided you start by branching from master I see no reason why merging would not work What might be slightly better would be the following: 1/ Announce that master is frozen on the mailing list, wait a little while to make sure everyone sees 2/ Merge master into jena3 to grab any small changes that have happened since the split 3/ Fix up any conflicts and build failures introduced as a result 4/ Merge jena3 back into master > >At this point master is jena3 and there is a jena2 branch. What is the purpose of the Jena2 branch, are we intended to provide ongoing maintenance and back porting of 3.x fixes for the 2.x branch? Or is it simply a convenient place for those who want to stick to Jena2 to work from? If we as a project don't intend to maintain the 2.x line then I see no reason to have a Jena2 branch and having the jena-2-3-split tag should be sufficient for those who want to continue to stick to 2.x Historically we have never supported multiple versions and our advice has always been upgrade when a user complains of a bug in a past version so I don't see that we would want to start now > >G/ delete jena3 branch. > >H/ Documentation/website > > >There are quite a few choices in the details - improvements welcome. >Experience doubly welcome. I've not done something as repo-wide as this >before. > > > Andy > >learnings for migration: > >L1/ Assembler files have class loading in them especially >com.hpl.hpl.jena.tdb. Maybe worth trapping during loading and changing >to org.apache.jena.tdb. Agreed, perhaps building a general purpose package redirection mechanism into the Assembler machinery would be a good idea > >L2/ "java:" custom filter functions (ARQ and Leviathan). Again, add >transition to the loading step. Yep that should be easy to do and in this case the redirection mechanism already exists I believe? > >L3/ slf4j/log4j : logger names The logger names or the package names mentioned in the log configurations? > >L4/ Can collapse some module versions to track 3.0.0 (jena-text, >jena-spatial ...) Yep that would be nice and probably required since changing the package names is certainly a breaking change for most people and setting everything to be 3.0.0 would make it clear a major bump happens I would go so far as to suggest that we bump all versions (bar parent) to a 3.0.0 baseline just so no-one can moan that we didn't follow SemVer practises properly Rob > > >On 24/01/15 18:33, Andy Seaborne 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 >
