Re: Test release for 1479

Matthew John Toseland <[email protected]> Sat, 14 Oct 2017 21:20:39 +0100

Newsgroups	gmane.network.freenet.devel
Message-ID	<[email protected]>

On 14/10/17 19:42, Arne Babenhauserheide wrote:
> Matthew John Toseland <[email protected]> writes:
> 
>> On 14/10/17 13:16, Arne Babenhauserheide wrote:
>>> Hi,
>>>
>>> I’m slowly moving towards being able to release somewhat risky changes
>>> on the new infra again. As first concrete step,
>>> freenet-20171010-r1-snapshot.jar updates update.sh to be able to pull
>>> new fred releases directly from github. It only covers
>>> freenet-stable-latest.jar, but that should be enough to recover by
>>> uploading a new release which ships new files via Freenet. This will not
>>> suffice if connectivity plugins are broken, though.
>>
>> That sounds risky. What about the other dependencies - freenet-ext.jar,
>> Bouncycastle etc? Bouncycastle for example may well be necessary for UOM
>> to work.
> 
> As long as no *new* bouncycastle is needed, this should not hit us. This
> measure is to be able to release more invasive updates again without
> having to worry that users might be left without any way to update back
> to a working version.
> 
> I would prefer to have a better version, but that will do much bigger
> changes and we are currently without *any* way to update via clearnet.

More invasive updates that don't involve changing any files other than
freenet-stable-latest.jar?

The old update scripts just had the other jars hard-coded. So they
needed to be updated if we add a new dependency (but that will just work
because we update the script itself first). Is there any reason we can't
have that? Surely FPI has the ability to host (open source) files such
as the dependencies?
> 
> Best wishes,
> Arne
>

signature.asc (application/pgp-signature, 833 B)