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 ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Jsynthlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
