I'd prefer (2). It's clean and it _uses_ VC instead of working around it. My only concern is that we should do it before people have a chance to fork, because they'll want to do that as late as possible. But we can ameliorate that by just making a couple of loud announcements first. We might want also to make a point of pointing at replacements, even if they seem obvious to us.
ajs6f > On Nov 29, 2018, at 11:45 AM, Andy Seaborne <a...@apache.org> wrote: > > Let's retire some modules: > > jena-spatial [+] > jena-fuseki1 > jena-csv > > by not including them in the next release; they should all work but there > isn't a way to signal "deprecation" other than by talking about it (which > we've done) and doing it. > > There are several ways to go about this. > > 1/ have an area "archived/" with the modules moved there. > This leaves them in the source-release and browsable in git. > > 2/ Delete from git. Maybe leave a file somewhere to record the commit ids. > > 3/ A new separate git-repo for "jena-misc" > https://git-wip-us.apache.org/repos/asf/jena-misc.asf > (or use gitbox and put it on github mirroed back to ASF.) > > and maybe some others. > > I think (1) is not definite enough. > > Thoughts/suggestions/... > > Andy > > [+] > jena-spatial :: this is in jena-fuseki-webapp > [INFO] +- org.apache.jena:jena-spatial:jar:3.10.0-SNAPSHOT:compile > [INFO] | +- org.apache.lucene:lucene-spatial:jar:7.4.0:compile > [INFO] | +- org.apache.lucene:lucene-spatial-extras:jar:7.4.0:compile > [INFO] | | +- org.apache.lucene:lucene-spatial3d:jar:7.4.0:compile > [INFO] | | \- io.sgr:s2-geometry-library-java:jar:1.0.0:compile > [INFO] | \- org.locationtech.spatial4j:spatial4j:jar:0.6:compile
