Put Major Releases in Subversion

TThe idea is to have all the major releases (AthensRelease, BeijingRelease, CairoRelease and all the releases to come) in the branch directory of Subversion. This serves 2 purposes:

1. (And most important) Major releases are versioned, so is easier to keep track of patches that needs to be applied to them, like any security patch we could issue from now on. (and is easier to create the diff)
2. Easy access to the major releases for developers (somehow a minor purpose)

Of course, write access to those branches should be restricted to the CoreTeam.

-- RafaelAlvarez - 23 Nov 2004

Actually, you want to use the tags directory. branches is for modifications (ie. work in progress, either off of a release point or for work that will later be merged to the trunk). For instance, the 20040901 release would be in both tags and branches but the latter would probably be renamed to reflect that it's the branch where work on the security fix happened. Once complete, the head of that branch is copied back to tags/20040902 to reflect the new release.

-- KennethPorter - 23 Nov 2004

After digesting what you said... Yep, you're right. They should be in tags.

I'm still with the CVS mindset

Any more opinions on this?

-- RafaelAlvarez - 27 Nov 2004

I quite agree, i just havn't found the time or energy. In the short term, we are patching older versions by unpacking and repacking the release tarball (as the creation of the tarball is currently a mystic manual process. In the long term we hope to have fully automated release builds - but that support still needs a heap of work (going on in DEVELOP)

-- SvenDowideit - 27 Nov 2004

shouldn't they have already been imported over with cvs2svn ?

-- WillNorris - 22 Mar 2005