It would be also good to hear other thoughts on this,
and get to an agreement whether to do "branching"
(parallel development) or "tagging" (linear). First
needs syncing, allows more dynamic development,
the seconds will slow development, but it requires
less (human) resources.
One more - important - thought:
Branching is also for minor bugfix revisions,
not just RCs, so if we consider this, there is simply
no way to get around it. Let's say we're releasing
stable 1.0.0 today; if we completely want to avoid
parallel development ("real" branching), we should
either wait for an indefinite time to get all the
bugs and release 1.0.1 -> 1.0.2 -> 1.0.n. Or, if we
continue development (which we definitely want to
do), we will not be able to release 1.0.1, since we
did and do all the development in one branch.
That's the reason SVN dropped tags and uses
branches only.
This is not black & white of course, because
we can mix the two concepts for best results, by
having branches for main versions (1.0, 1.1, 2.0),
and having "read-only" branches (tags) to store
released codebases (just to make it easy to find
them without remembering the revision numbers).
So, if we consider the above, we should have names
'harbour1.0.0RC1' as 'harbour-1.0'.
Ugly ASCII art:
+--- 1.0
| +-- 1.0.0RCn
| | (fixes)
| +-- 1.0.0
| | (fixes)
| +-- 1.0.n
|
| (development)
+--- 1.1
| +-- 1.1.0RCn
| | (fixes)
| +-- 1.1.0
| | (fixes)
| +-- 1.1.n
|
| (development)
+--- 2.0
| (development)
...
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
