| Age | Commit message (Collapse) | Author |
|---|
|
This is a major step because solr removed support for embedded solr
instances in 9.0 and we want to keep it because we want to ship
YaCy with an embedded solr. It was necessary to add parts of solr
code into YaCy to make this migration possible. Further on with
Solr 9.1 they removed even more parts which are required for embedded
operation, therefore we cannot migrate yet further without big
changes.
If you are running a YaCy instance with Solr 8.x, the migration should
be done automatically. If not you require to first migrate to a YaCy
version 1.93 with Solr 8.x to migrate to Solr 8 data.
|
|
packages, most important solr which will be migrated from 8.9 to 9.x
|
|
all commits will now be automatically published at
https://release.yacy.net/
|
|
...without reference to 9000ish SVN
|
|
|
|
The releaseNr is now set to a static value in build.properties. We
can increment it there manually and eventually switch to another
version number scheme if we like.
|
|
The https://reproducible-builds.org project invests a lot of work
to make builds reproducible. This is a security property. It allows
to compare the build of binaries from different builder machines.
If they are identical, it means that either the builds have not
been manipulated or an attacker managed to attack all builder
machines in exactly the same way.
One problem that the reproducible-builds project often sees is
that projects include the build time in their binaries. This
makes builds unreproducible for apparently no reason. The build
date should not be of interest since binaries built on different
dates but from the same source code should not be different.
Thus I decided to remove the build date instead of re-implementing
the functionality without the GitRev task. Anyways the reported
date was not the build date but the date of the last git commit
which is even less informative. The git commit ID would have
information value but should only be relevant for "nightly builds".
|
|
First commit of a series to get rid of the git based versioning
implemented in libbuild/ folder as Ant task. It counts commits
since the last tagged version and uses this number added with
9000 as the last part of the version number.
This is a legacy from Subversion times.
|
|
ATTENTION: old indexes from solr 6 CANNOT be migrated to solr 8
DO NOT use this version if you still have a solr 6 index.
|
|
|
|
|
|
Also: now Version 1.921
|
|
|
|
|
|
|
|
|
|
|
|
commits, maybe new and unstable things will come...
|
|
|
|
This includes also a small code change to test generic type inference, a
java 1.7 feature
|
|
|
|
It's nowhere explained or declared, but since some time we follow the
schema that uneven version numbers are used for development versions and
even numbers for release versions. That concept may change sometime but
this is used at this time to distinguish development from main.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
with javabin format capability
|
|
|
|
|
|
|
|
|
|
|
|
the past)
|
|
|
|
|
|
|
|
|
|
|
|
for production as a replacement of the metadata-db.
This intermediate release 1.041 will switch on the previously optional
solr index and the old metadata-db will still work as it did before.
Solr+metadata are accessed in mixed mode, no migration is done yet.
If this causes not a catastrophe until the end of the weekend, we will
do a YaCy 1.1 main release containing this as default.
|
|
|
|
|
|
|
|
do not handle the revision in build.properties anymore
(9000 as fallback)
build-date from git-HEAD (instead when build is fired)
(orginal build-date as fallback)
|
|
|
|
|
|
|
|
|
