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.
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
