On Wed, Jan 04, 2006 at 10:34:41PM +0000, NextGen$ wrote: > 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
0.6/0.5 please. > > ************************************************************************* > We reorganize the downloads/ directory as such: > > /downloads/ > /seednodes > /seednodes-0.5.* > /seednodes-0.6.* > /seednodes-0.7.* One file for each branch? > /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 > So we tag by date? At least during prerelease? Not bad. We can then make releases in the same way, by committing to e.g. /tags/0.7.1.3 > 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$. Not bad. -- 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/20060105/a5ac1e39/attachment.pgp>
