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