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
