On 05/11/14 04:37, Steve Dougherty wrote: > The prerelease tagged as testing-build-1466-pre1 is available via > update.sh|cmd testing. Inserts are in progress. > > I just pulled the Fred translations from Transifex; if they are wrong or > out of date they require updating. > > 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? > I was hoping to write a "hey you just upgraded, here are links to the > release notes" alert, but haven't gotten to it yet and don't want to > hold up the release more to do it. Would anyone care to write such a > thing? I'd also like to start bundling Winterface as an experimental > plugin. Does anyone want to review it or shall I just drop it into 1467? > > My understanding is that to update (or add) a dependency one must: > > * insert the dependency > * upload the dependency to the website (for update.sh|cmd) > * edit Fred dependencies.properties > * edit the Windows installer build > * edit the Java installer build > > 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. > 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
