yacy/build.properties, branch masterYaCy search server with some extra patches
https://git.fennell.dev/yacy/atom?h=master2026-07-10T20:47:39ZWe migrate to JDK 172026-07-10T20:47:39ZMichael Peter Christenmc@yacy.net2026-07-10T20:47:39Zurn:sha1:dd0225bdde303cc739fed60c9aff28b63b868997
This is a hard requirement to be able to migrate
to a more recent jetty version, which may happen sometime soon.Release_1.941 - The AI Release2026-03-29T09:24:35ZMichael Peter Christenmc@yacy.net2026-03-29T09:24:35Zurn:sha1:f0464e7fbcfcb69127f0325910f92f113ce23677migrated solr to 9.02024-05-19T15:34:57ZMichael Peter Christenmc@yacy.net2024-05-19T15:34:57Zurn:sha1:8eb0d490aa486e4ade9dd40f4da433e3dc5f4ed6
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.Migrated from java 8 to java 11. This step is required to upgrade certain packages, most important solr which will be migrated from 8.9 to 9.x2023-08-31T15:52:30ZMichael Peter Christenmc@yacy.net2023-08-31T15:52:30Zurn:sha1:6bd5f49c412be8edaadc5bc707dcd2a521207da5new release number schema and CI processes:2022-10-04T14:14:40ZMichael Peter Christenmc@yacy.net2022-10-04T14:14:40Zurn:sha1:e931b80cf111a07c2dccf0fc4bc82fc79b8a3fa5
all commits will now be automatically published at
https://release.yacy.net/new release file names with date and git hash2022-10-04T13:31:47ZMichael Peter Christenmc@yacy.net2022-10-04T13:31:47Zurn:sha1:60c9986a0e4a4f4f75e1ba93e6cf1ac0f9f1fed6
...without reference to 9000ish SVNcreate release file path in ant process and explicitly make build dir2022-10-03T10:01:23ZMichael Christenmc@yacy.net2022-10-03T10:01:23Zurn:sha1:56aa23a3ca315db011faf611faa1450c4a7a32farm GitRevTask2022-07-10T12:33:28ZThomas Kochthomas@koch.ro2022-07-10T09:43:03Zurn:sha1:c98d09b664fe2a6f69b99f035a73c4d78e16c7db
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.
rm buildDate from build.xml and its usages2022-07-10T11:32:38ZThomas Kochthomas@koch.ro2022-07-10T09:13:34Zurn:sha1:3116713672bbcf6aec50439537e451646bc9a11a
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".
remove unused branch property in build.xml2022-07-10T10:14:46ZThomas Kochthomas@koch.ro2022-07-09T17:39:30Zurn:sha1:b661cc56d8d119d1788bb70df84f1a76809b5924
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.