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? > > 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)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
