Hi Phil,
There may be multiple branches, but they need to be clearly defined
on what
can be done to them.
Likely, something like your diagram, though.
Yes, see my mail. In the ASCII diagram in it, there
is basically two development paths at the same time.
One in the main branch, and one is the latest x.x
version branch.
As for the versions, I'd keep it simple: 1.0.x, no
Service Packs, just 1.0.0 (which is Final, no need
to add that), the only postfixes are betas and RCs
(maybe alphas).
For now, it's a problem we can tackle in the future.
Not really, I think we should do this beforehand,
because this way I've already wasted days doing
something which wasn't necessary.
When we mark 1.0.0-Final, we will also branch it to 1.1.0-dev where
ongoing
work will be done.
An 1.0, 1.1 branch will suffice, which is is the "dev"
branch by definition.
Any branches to 1.0.0-Final will be for service packs, like 1.0.0-
SP1, which
should retain nearly 100% 1.0.0 compatibility and smash any big
bugs. If
there are no big bugs, there should be no SP1.
The old branches need to be left alone. There is no point in
updating them. If
you want to work on multiple fronts, those branches should be made
from the
most current branch you wish to base your branch on. Not something
in the
past that needs to be caught up. That method is a waste of time and
breaks
things.
For now, I have asked developers to put enhancements on hold and
concentrate
on getting a stable 1.0.0 to the world.
Do you agree with such a branch layout and versioning?:
+ harbour - commit all new developments
|-+ harbour-1.0 - commit 1.0 fixes only ("1.0dev")
| +-- harbour-1.0.0RCn - read-only for RC release
| +-- harbour-1.0.n - read-only for final release
|
|-+ harbour-1.1 - commit 1.1 fixes only
| +-- harbour-1.1.0bn - read-only for beta release
| +-- harbour-1.1.0RCn - read-only for RC release
| +-- harbour-1.1.n - read-only for final release
|
|-+ harbour-2.0 - commit 2.0 fixes only
| +-- harbour-2.0.0bn - read-only for beta release
| +-- harbour-2.0.0RCn - read-only for RC release
| +-- harbour-2.0.n - read-only for final release
| ...
|
...
Given enough time between major (x.x) releases
it's expected that development will be done in
the 'harbour' branch, and post-release bug fixing
is done in parallel in one of the 'harbour-x.x'
branches at a time. 'harbour-x.x.x*' branches
are all _read-only_.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
