Re: Test release for 1479

Matthew John Toseland <[email protected]> Sun, 15 Oct 2017 17:36:13 +0100
Newsgroups	gmane.network.freenet.devel
Message-ID	<[email protected]>
On 15/10/17 10:02, Arne Babenhauserheide wrote:
> 
> Matthew John Toseland <[email protected]> writes:
> 
>> 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?
> 
> Once we can update freenet-stable-latest.jar to a version which
> connects, we can use dependencies.properties to update other files.

Sometimes. Not reliably. Sometimes you really do need to make breaking
changes, especially if the connection crypto changes. That's why we have
dependencies.properties. The on-Freenet updater code checks it *before*
deploying the new 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?
> 
> Yes, it does. But we have to rebuild that capability because what we had
> got lost with downloads.freenetproject.org.

So this is a temporary kludge. Eventually update.sh/update.cmd will
update all the files. Maybe we could auto-generate them from
dependencies.properties even.

I do think it is a good idea to maintain upgradability for as long as
possible, as long as the cost of doing so is reasonable.
> 
> Best wishes,
> Arne
signature.asc (application/pgp-signature, 833 B)