I propose that: - We don't increment the build number unless the changes are considered reasonably stable - after it has had some testing; more disruptive changes should wait for some end-user feedback. - We have two separate redirects on emu. freenet-cvs-latest.jar should only be updated when a new stable build comes out i.e. when the build number is incremented. Because the name is misleading, this should be a link to freenet-stable-latest.jar, which the installer should henceforth use. freenet-testing-latest.jar should be updated on every commit. Only core devs should have commit rights to Version.java. We should ship two versions of update.sh/update.cmd, one for stable and one for unstable. The stable version is only for emergencies, and should say so. The unstable version is for prerelease testers, and should also say so. - Helpful geeks (prerelease testers) can use update-unstable.sh. - Possible extension: We could have a separate update stream for unstable builds. Since this is only used by prerelease testers it need not be so secure as the primary, so emu can automatically insert new builds. It's probably not possible to run a node on emu, mind you...
[20:09] <mYone> uhm guys, when and how exactly does the autoupdate kick in? fproxy always tells me that theres a new version available but i dont see it being downloaded or trying to install anywhere... [20:09] <dbkr> mYone: I'm guessing you have advanced darknet enabled? [20:11] <edt> mYone, fproxy sees one of your peers with a newer version. It may still be experimental. Once one of the 'experimental' builds is declared stable enough, its inserted into freenet and the auto update will find it and update [20:13] <edt> mYone not every build is good enough to push to all of freenet [20:13] <mYone> dbkr: yep i have [20:13] <mYone> edt: ah, ok [20:14] <mYone> all those great new features are giving me headaches after long absence from freenet ;) [20:16] <dbkr> What do people reckon to only showing peer version numbers in advanced darknet mode, and getting rid of that 'there is a newer version available' message altogether? [20:17] <toad_> it's important that people do update [20:17] <toad_> otherwise they will be left behind [20:18] <toad_> but we should get rid of the message yes [20:18] <toad_> or at least put a caveat in [20:18] <dbkr> I'm just thinking that the audo updater should handle the job of telling people there's a new version available. [20:19] <toad_> yeah [20:19] <dbkr> your peers having newer versions than you do but you not being offered a new version is kind of confusing [20:19] <mYone> toad_: just my newbie thought: cant you just add a 'experimental' flag, so experimental versions are not shown as being 'new version available'? or anything like that... [20:20] <toad_> well we could just not up the build number for them ... [20:22] <mYone> or that ^^ then there wont be confusion about it ;) because in general i like that info box, its good to know whether you are up to date or not [20:22] <dbkr> toad_: that's possibly a better option [20:23] <toad_> in fact ... [20:24] <toad_> I suggest that *unless we up the build number*, not only do we not insert it, but it's not automatically deployed by emu to the update.sh'ers (and in particular new installs) [20:24] <toad_> we should have an unstable build somewhere on emu for testers, separate from what is used by the installer [20:24] <toad_> sound good? [20:24] <dbkr> yes, I like that idea. [20:25] <toad_> then we don't have to have a separate unstable branch, but we get the benefits of early testing, and newbies don't have to deal with unstable builds... -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060805/60b8b3a5/attachment.pgp>
