Hi, Here is the problem :
We do need freenet-ext.jar for both alpha and legacy code but unfortunally, the legacy code is mandatory to build freenet-ext.jar :/ So here is the proposal : ************************************************************************* We keep a copy of /trunk/contrib into /branches/legacy/<.[0-9]>Contrib and build futhurer "legacy" build manually using this Contrib directory. To sum up, we drop support for auto-releasing new releases for decapreted branches... and we rename /branches/legacy/unstable and /branches/legacy/stable to /branches/legacy/.6/ and /branches/legacy/.5 ************************************************************************* We reorganize the downloads/ directory as such: /downloads/ /seednodes /seednodes-0.5.* /seednodes-0.6.* /seednodes-0.7.* /0.5/ /win32/ *.exe /freenet-5106.* /freenet-latest.* /freenet-ext-5106-<svn-revision-number>.* /freenet-ext-latest.* /0.6/ /win32/ *.exe /freenet-60275.* /freenet-latest.* /freenet-ext-60275-<svn-revision-number>.* /freenet-ext-latest.* /0.7/ /freenet-0.7-YearMonthDay-<svn-revision-number>.* /freenet-latest.* /freenet-ext-0.7-<svn-revision-number>.* /freenet-ext-latest.* /LATEST/ /freenet-latest.* /freenet-ext-latest.* /snapshots/ /freenet-trunk-YearMonthDay-<svn-revision-number>.* /freenet-latest.* /freenet-ext-trunk-<svn-revision-number>.* /freenet-ext-latest.* LATEST links would be symlinks... and .* a set of .zip/.bz2/.gz or .jar/.tar where appropriate IT WOULD REQUIRE UPDATING THE WIN32 INSTALLER :'( but seems easier to manage and maybe more clear than the current tree. (I'm speaking about http://downloads.freenetproject.org) ************************************************************************* We change the release numbering and process : each build will have : an identification string (eg: 0.7 or dev-0.7) a svn revision number (eg: 7739) in Version.java, we keep: lastGoodBuild, buildNumber and nodeVersion, the rule would be : if lastGoodBuild>remote_buildNumber and nodeVersion==remote_nodeVersion then, connect. ... nothing really new, except that we will update the buildNumber "on commit": Only a few "trusted devs." will be able to commit to /tags and "release an official build". Committing there will update the buildNumber automagically. /tags /0.7-0601042225 for example (no revision number) /ext-0.7-0601042225 Any dev will be able to commit to /trunk and it will generate a new snapshot each commit. Officials snapshots will be built against official -ext files. ************************************************************************* Any though about that ? It might be a bit weird for the end user as next build won't be buildNumber+1 ... but I hope he can deal with it :p Regards. NextGen$.