On Saturday 13 Oct 2012 00:20:02 Steve Dougherty wrote: > On 10/12/2012 03:34 PM, Steve Dougherty wrote: > > 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. > > So we're opting not to decouple the network version and build number > on official releases? Not doing so certainly simplifies the > correspondence between the two, but it's also true that official > releases are often followed with bugfix releases, and these do not > necessarily include changes which impact network behavior. This > changes the concept from a network version to an official build > compatibility version, which strikes me as more difficult to keep up > with and less flexible - both in the current state of things and a in > the possibility of an official build compromise or stagnation.
That makes some sense. It would make testing builds trickier though. If we do them automatically they wouldn't correspond to a specific tag, and if we do them manually they'd take more work. Ideas?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
