Upon release of 1.6.0 on the web site, we contemporaneously reorganized
the SVN structure. It was basically a "blow up and start over"
operation and was undertaken using Tortoise/SVN sledge hammers. After
consulting with Eric and receiving advice from others we made the
changes, and then made further changes upon learning we had move things
around using the wrong "svn tool". To you the user, it would almost
appear that nothing happened on the last step, but never mind, the first
step was probably a bit traumatic and the last one was a blip in
comparison. I did it incorrectly on the first step and fixed it in step
two.
Let me explan what we have done and how I understand we will be using
the SVN repository. This is subject to change at the behest of Flex
Radio now that I have set this up in cooperation with Eric and Dale and
is managed by Flex Radio and its employees (I am not one).
A "typical" svn repository has a trunk, tags, and branches and though
there are no hard rules, we believe our use of the svn repository is
now "standard". I will explain by example.
The moment of release on the web site of the next release (say 1.6.1),
the frozen copy of the code/docs/executables involved in 1.6.1 will be
"thin copied" from the trunk to a tag in the repository. The tag will
be 1.6.1 and will preserve the state of 1.6.1 in perpetuity. All
ongoing work will be done in trunk and branches. Releases will be in
tags. If you are a developer with write access to the repository and
you attempt to modify code in a tag at the repository, tortoise svn will
send out a shout to you in a error/dialog box on the screen telling you
this is nonstandard and will ruin the structure but go ahead if you insist.
Let us suppose that the Bill/Phil effort towards a sound card free
widget comes into the project. They will get there own branch. Suppose
Jeff wants to do a console and maintain it. He can get his own branch.
When and if everyone agrees on the merger, they will be merged into
the trunk and it will be revert to what is clearly an "alpha" status.
In every svn project I participate in, everything in the trunk after
release (and thus preserved in a tag) is the ALPHA version of the next
release. It becomes as it stabilizes, BUT REMAINS IN THE TRUNK, I
guess you could call beta. When the developers are satisfied that the
bugs out and that it is stable, a release is built and the process
repeats. The Alpha, Beta bit is clearly muddied by the use of svn.
This is standard operating procedure, However, in many projects (alsa,
jack, python, wxwidgets, wxpython, fftw, and MANY more), a tar ball
is made of the "prerelease" code and put up for normal browser or ftp
download. Everyone is requested to beat it up for a short period
before the "final" comes out and the final release date is published
when the release candidate is proposed.
Should anyone have an alternative point of view on this about our
interpretation of standard usage of svn, please send a note to Eric. He
is the official Flex maintainer.
Bob
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540
(609)-924-4600
(This sig is required by my employer)
