-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJQeKWiAAoJECLJP19KqmFuc/UP/3cnM+x7ADX9pDWfMavLPE0W +JQ9FPXAbQXpylNCBjQUKSEkBoB9V7vL9x6lE2CdjIZvGxrGRbuzIezeQxixHsie snGf60EuRsII8OaPyjsDF3vQg7kT8+oq3BjEeO96QDIyyVh8Lwg4HXse4np8dLEW GvDps6Br5L10IvEbIO1u1i28owSFrQZaat9HGKmZdZfGnvqmhtF7mSjS7TaDN6hf lCJPQP6Onx5EKM0iDHB54f8h+/aonsUQ+F1nFjpe8KO1iDWYFvLcfO7vlKqzDrdR pMb9uzNZ2jzETUn9Vd2UBpx82NA/Bkoi1CrOfGUvbcr0stxEj1L9xzloJ7ov2WXx ag1yDac9lV+Ehel/tDrENPXzkf6qsXsIy73CpB5UfIFjf2Nt1s/sQfToOTQhzf2G 5eIEga3Ldki4Ea0a7px6x/DEymvMvbRFMFbJz6QrSmqjs+komtsWlRTaGBr0Hz0j 1Fj89phyKDcYzQI4UfjzPDVR7no5ZVQUhHuC0+Un1iRAfvw8FKfUhsWKOUY2fKNv 28H5SNAWIlegg/3GsQ3gb+Vn5n/4IntoNOWZa7k+4XoOw4XZ6i/lr8EqFfynsVX1 NBsb2ljyJFx2nfRGKEoa4oM4hx6Pcp/MBVYFk9z9afqUfwFFVDWuZR843ocRgXcK R9azNMQB49ej7+FgX7hl =JFqg -----END PGP SIGNATURE----- _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
