The subversion architecture is pretty flexible. How we lay out the
tree is by convention, and convention is what we make it. The subtree I
created is meant to be "stable", and possibly frozen. In practice,
software that is frozen is software that keeps its bugs.
The difference between frozen and stable is a function of how many bugs
people want to fix. If you want it frozen, then don't change anything
in that subtree. My expectations are that this new subtree would get 2
to 10 bug fixes max before that subtree dies out and people switch back
to trunk a month or two from now. I don't really understand all the
commotion.
As to the remark about "branch" vs "tags", I saw no purpose in having
both of them for a release or a release candidate. A branch tree would
be useful for temporary "out of trunk" work, which eventually gets
merged and then deleted. This Nov-2007 release is no such thing. With
too many subtrees, it would mean that changes may need to be merged or
copied across to each one, causing more work. There are not enough
man-hours donated here as it is.
As for version numbering, IMO we have that in the svn mechanism. If you
want to describe a particular version, you can always do so as follows:
https://kicad.svn.sourceforge.net/svnroot/kicad/tags/kicad-2007-Nov@470
notice that @470, this is the subversion version number, and there can
be a small handful of them in the kicad-2007-Nov subtree.
or
svn switch
https://kicad.svn.sourceforge.net/svnroot/kicad/tags/kicad-2007-Nov@470
Within the kicad-2007-Nov subtree, there will not be a lot of separate
versions, at most two months worth, maybe 2 to 10 bug fixes. If you
like a particular version other than the most recent found within the
subtree (which presumably would have the largest number of bugs fixed),
then remember the subversion version number for it and tell your friends
about that so they can check it out.
Nothing I have heard in the most recent postings persuade me to believe
that we are going down anything but the best path.
