On 14/11/14 03:51, Steve Dougherty wrote: > On Nov 5, 2014 7:04 AM, "Matthew Toseland" <mj...@cam.ac.uk> wrote: >> On 05/11/14 04:37, Steve Dougherty wrote: > ... >>> I had hoped to release 1466 last weekend. That didn't happen both >>> because we decided it should have more testing before release, and >>> because updating dependencies is more involved than it should be. Would >>> it make sense to update Bouncy Castle to 1.51 manually and try to move >>> to a single point of maintenance for future releases? That's my current >>> plan unless people feel otherwise. >> I don't understand. What is the problem? The dependencies file can >> replace any required library, we've used this in the past? > The dependencies file is certainly a great improvement over manually > writing upgrade code for each upgrade. My point is that upgrading to > Bouncy Castle 1.51, in addition to updating dependencies.properties, > required manually: > > * inserting the library > * uploading to /alpha/deps/ > * redirecting from /latest/ > * writing upgrade support in update.sh|cmd > * updating the installer builds to bundle the new library > > ... >>> None of this requires thought, and replacing steps performed by squishy >>> humans with a script seems likely to be faster and less error-prone. >> Yes... Ideally we'd like to do an upgrade-test too though. > As in an upgrade unit test? Not strictly a unit test, more of an integration test. But some sort of automated whole-node-upgrade testing. >>> Also update.sh|cmd contain what are effectively shell / batch script >>> reimplementations of parts of the Node updater. Would anyone be >>> interested in breaking out the deployment part so that both scripts can >>> call the node jar with a main class that will fetch over HTTPS, then >>> deployment proceeds as usual? Verification is currently sha1; is knowing >>> the key alone (like from dependencies.properties) enough to know the >>> file's checksum? If we switch to verify signatures how should we ship >>> keys? >> IMHO update.sh / update.cmd should work even if e.g. we have somehow >> managed to corrupt the node jar, e.g. it's 0 bytes long, wrapper.conf is >> broken, etc. They are supposed to be for last-resort recovery, so users >> don't need to reinstall. > Unless we suspect that there are either updater bugs or common system > failures that lead to zero-byte jars, I'm not convinced it's worth the > additional maintenance burden and additional opportunities to introduce > bugs. If we move the updater into the jar it could repair the > wrapper.conf when invoked from a script. (or directly) This has happened lots of times before. IMHO it is common, and being able to recover without doing a full reinstall is a useful feature, especially if we want people to use darknet.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
