Alexander Klenin schrieb: > On Thu, Apr 16, 2009 at 00:02, Florian Klaempfl <flor...@freepascal.org> > wrote: >> Very difficult. If a release is created from a branch, nobody can ensure >> that all release builders built the release candidate from exactly the >> same revision, if they don't, things might be broken when the final >> release should be built. > > Why not tag it x.y.z-pre1 then, and if all went well, additionally tag > the same revision > as x.y.z, otherwise create x.y.z-pre2 etc.?
What if you realize after x.y.z has been tagged, built and uploaded that it has a security hole as it happend with fpc? > >> At cvs times we did this for fpc and we had to lock the branch to >> prevent commits (btw: can git lock branches ;)?) > > Git (and Subversion too) can, in principle, "lock" branches using > pre-commit hook. Subversion has a native lock command ;) One can override it, but this is behaving really bad and I don't expect anybody to do so. > However, note that in git the whole problem does not exist, since in > the normal workflow > nobody except release manager can commit to "release" branch anyway. So the release manager needs to run his own git repository instead of having the release tag in the central, fast and reliable repository? The sad thing about this workflow is anyways, that no release manager can test all patches because he lacks the appropriate machines so he needs to merge patches blindly. > Also, it you _do_ move a tag in git, everybody updating from your > repository will > get a big fat warning ;-) > This is fine, but sometimes moving a tag is needed. Period. _______________________________________________ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus