-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/09/2012 05:54 AM, Matthew Toseland wrote: > On Sunday 07 Oct 2012 18:01:58 Justus Ranvier wrote: >> The following tree contains a change to Version.java that allows >> alternate Freenet builds to work transparently with official >> builds in the network. >> >> A new variable is introduced, networkVersion, which is reported >> to peers instead of buildNumber. It turns out this was easier to >> do than rewrite NodeUpdateManager to break the assumption that >> edition number of the UpdateURI was the same as buildNumber. >> >> This tree has the change: >> >> https://github.com/justusranvier/fred-staging/commit/41962370ad797844f2015935b14ce9faa284e8fd >> >> >> This tree is a proof of concept which starts out with buildNumber 0 but >> reports build 1417 to its peers. I have tested it to verify it >> will discover and download updates from a keyspace I control >> while connecting seamlessly to opennet and darknet peers which >> run the official build. >> >> https://github.com/justusranvier/fred-staging/commit/482fbe1fc7084072cb7a58cff686ca0a259d245a >> >> >> If you want to test this proof of concept, download this key and save it >> as freenet.jar: >> SSK@virOTvBfehYSm3JZGAHI8aUg1mROfclxMRBkvkwYIHc,pSr0VwTMXZEF5TwQMN7fW9cBEB58NzaFGZxurlIL71E,AQACAAE/update-0 >> >> >> Then start it using a freenet.ini without a node.updater.URI line. The >> node will discover new builds 1 and 2 and will upgrade itself as >> long as automatic updating is enabled. Any peers of this node >> will see it reporting version 1417. >> > That's a very good idea. We should use this for official testing > builds. Making it easier for individual devs to publish a fork is a > good thing, on balance, although obviously will exacerbate some > minor problems. > > So what's the easiest way to use it for testing builds? I'm > thinking of merging issues ... When I release an official build, > the first step is to run the tag-build script, it could change > Version.java appropriately? Or we could do it the other way around, > e.g. releasing a snapshot could update the buildVersion? > > Also, should Version.java (or MANIFEST.MF, or both) include some > indication of which update stream a release belongs to? This is > probably a good idea? This could be either the URL for the > auto-update or just a plain String? The problem with using a URL is > we will occasionally need to change the auto-update URI; the > advantage is it is more of a unique identifier than a plain String > is ... > > Possibly the cleanest solution might be this: - networkVersion is > updated on an official release. - Official releases have > releaseStreamName = "official". - Pre-releases have > releaseStreamName = "official-testing". - If > releaseStreamName.equals("official"), we return networkVersion for > everything. Otherwise we return networkVersion. The variables are > final so this will get optimised out at run time. - The release > scripts check/enforce the above constraints. - Third party releases > have a different releaseStreamName. - The release scripts can be > configured (using a file in /home, like some of the functionality > already uses) to enforce a different stream name.
How about not having a release stream name, at least for decision-making purposes, and instead the official build release scripts enforce that the network version is the same as the build? A release string for human purposes would still be possible, but should probably be limited to the version reported on the statistics page, which makes more sense to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJQeHCkAAoJECLJP19KqmFu6VcQAJiIFJUFd5iB7OTTHl7I39E8 zrisInaKOH3acAmA0of2T03766GcxhV95elWsqSNVuCdi4sb3tsoGGoWEWnT/keg LbchzUUOjoXFo1ecGCnKGuocsNik+fXmAnqPG6qz0ZcLCVsOoFxMbUz4vqz2GVts YrLpcQYihZlsGOj3TMoY6I+fJjY6tmhMJ3owsAqsB2NRnEy670UrJ7gntmQOlN+J dd8i58iiFyQUr4mMDBB91xFMRxPi6niWQQsF9QHamwhnIyScZyLml0LUOEEh1r95 zHwKIVacAflKowJpgSvk2YjszcIcsSWvy/yd0Ncs2W1Frajt1mKK0PLN10G9z3lI bR+oasH8eABZWndDtV8Is0uolGDsUPmYZ7I1mLeIAmXtoLSqKbpcy6xqI2aaTNa5 AvLnlXVS4jIsRZ7CRrrI4nPYTJqivMBTWxdpB2H5WewuCUl52VprZW0qUMnkAWu9 IBcNP6IRJ9mfMzn6AA8gGZzZ+/0mqXfihMrruqHQaEavhI9lSRqj1CWoW7lPabJs Xzt8GGyvtKn9AjnhcFONUlR4uCScl5x7rsSBULBszaL4ARl6QXb5D2mCyHGohu81 MVndDWZb6xkyhU4hI5A6RiewhlCTtklbYzb97bwVeZDbzcX5PTq+t3awJY6UjWfR 0EwBuSdlWDFE2EwUfdg1 =S+28 -----END PGP SIGNATURE----- _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
