Re: [Jsynthlib-devel] Name for refactored branch

[Joe E. <jo...@em...>]

On 09/02/2011 10:13 AM, Vladimir Avdonin wrote:
> Well, I have different phylosophy - I believe no development shall
> happen trunk, it shall stay clean and functional at any moment.
That sounds like you're saying that, at all times, checking out from 
trunk should give you a release. That's different from how I've heard 
revision-control systems described in the past.

Basically, the story I usually hear is:
1 - Trunk is dynamic, and always in flux. *Most* of the time, compiling 
from trunk will give you an application with bugs or half-implemented 
features. But trunk *should* compile without errors, generally. Bugs, 
where things in the successfully-compiled application don't work quite 
right, those are okay.
2 - When a release is coming up on a quiet or small project (let's call 
it 2.0), the devs can issue a feature-freeze and focus only on bug fixes 
in trunk until a release is made. Then, a tag is created for that 
release, and then work can begin on the new round of features in the 
next version (3.0). This method doesn't allow for issuing bug fixes for 
older versions, however. If an end user wants a bug fixed, they have to 
wait for the next release. Fine for small projects.
3 - If there's the need to issue bug fixes for past releases, then you 
need to branch, and you've got two options:
  3a) Branch off 2.0 and let bug-fixing happen there while new features 
and development toward 3.0 happen in trunk.
  3b) Branch off a copy of trunk for work on 3.0, while the bug fixes 
for 2.0 happen in trunk. When 2.0 is released, a tag is made for the 
current state of trunk, and then the 3.0 branch is merged back into 
trunk, and then the 3.0 branch can be deleted.

I think 3a is a much better way to go than 3b, for the following reasons:
- With 3b, all of the devs need to be told (and they have to remember) 
when the purpose of trunk changes. For example, when there's a 
feature-freeze, they all need to be told "bug fixes only in trunk until 
further notice". Then, when 2.0 gets released, they must be told that 
new features can now be introduced into trunk again. 3a avoids this; 
trunk always is the place for new features and bug-fixes which aren't 
version-specific.
- 3a doesn't require any merging of branches. Merging always brings the 
possibility of conflicts, so it's nice when they can be avoided.
- 3b doesn't really allow for bug fixes to previous versions. If you 
merge the 3.0 code back into trunk and then want to make a 2.01, what do 
you do? If you branch off the 2.0 revision of trunk to work on it 
separately, then you're basically doing the 3a method, so why not just 
start off that way?

So, if it were up to me, I'd branch releases (and only if there were 
going to be bug-fix work on old releases. If not, just make tags) and 
keep trunk "cutting edge". The only other time I'd make a branch is when 
there's some major development to be done which is going to make things 
*not compile* properly. If that happens in trunk, then other devs can't 
test their changes, so that needs to be avoided.

- Joe