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