On 24/04/15 14:22, Claude Warren wrote:
Do we need to verify that the Jena2 branch "works". That is that fixes can
be applied and the like?
IMO I think we should keep it working if changes are made to it.
There is a jenkins job to build branch jena2 (runs once a day if git has
changed)
As to whether to put fixes/changes into jena2, I find it hard to
advocate a definite rule. It all depends on the fix and the urgency and
the take up of Jena3.
I'm planning on backporting fixes usually (i.e. on case-by-case basis).
In practice, I think that'll mean small things I'll do, large ones I
probably won't. Otherwise, if somebody wants it, they'll need help out.
It's just being practical about it.
(I'm already feeling noble enough to have done SDB for Jena3!)
Andy
On Fri, Apr 24, 2015 at 2:06 PM, Andy Seaborne <[email protected]> wrote:
The process is at this point:
---------------------
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:
1/ Announce that master is frozen on the mailing list,
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.
G/ delete jena3 branch.
---------------------
Andy
On 24/04/15 13:25, Andy Seaborne wrote:
** RDF 1.1 enabled.
** java8 enabled.
** All versions are 3.0.0-SNAPSHOT except:
jena-parent (14-SNAPSHOT)
jena-fuseki1 (1.3.0-SNAPSHOT)
jena-fuseki (2.3.0-SNAPSHOT)
With a clean maven repository:
mvn -s ../setting-jena3.xml clean install
(the settings is a separate maven local repository)
jena-security => jena-permissions
Issue-ettes:
jena-maven-tools is commented out because it confuses the release plugin
for mvn release:update-versions.
