This is a discussion on Re: Proposal: rename v3-3-test to v3-devel - Samba ; -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One more thing, while the $SUBJECT says proposal, this is not a proposal at this time. Just a summary and thoughts for future releases. Sorry. Meant to change the $SUBJECT before I sent the ...
-----BEGIN PGP SIGNED MESSAGE-----
One more thing, while the $SUBJECT says proposal, this is not
a proposal at this time. Just a summary and thoughts for future
releases. Sorry. Meant to change the $SUBJECT before I sent
the msg out.
Gerald (Jerry) Carter wrote:
> (I see that Michael has beat me to the summary but since
> I've already spent some time on diagrams here, I'll still
> sending the mail out).
> This is an informative mail only for explanation and
> discussion. No changes affected by this mail. :-)
> There was a lot of discussion about the v3-3-test branch
> on #samba-technical so I'll try to summarize it here:
> Basically what we have in git history is
> ---- v3-0-test ----+---+-----
> \---- v3-2-test ----+---+-----
> \---- v3-3-test ----+---+-----
> --- v4-0-test ----+---+-----
> Since the Samba 4 branch basically has a completely separate
> code history, I'll ignore it for the branch discussion that
> My experience has been that developers like to continue coding
> while release managers like to stop it :-) So the only real
> way to keep both sides sane is to move the developers to another
> branch so that the rate of change in the release tree drops.
> Kai made the point that we are indirectly simply using
> a trunk & release model:
> ----- v3-devel (a.k.a. trunk) ----+----+----+----+----
> \ \ \
> \----v3-0 ---- \---- v3-2- \---- v3-3
> which is much more intuitive and actually requires less
> branching for developers, but more for the RM (release manager).
> All of these are variations on the same work flow we have
> always done when it comes right down to it.
> In an effort to reduce the confusion, the suggestion was
> made that v3-3-test should really be called v3-devel. When
> the November/December release is ready, Karolin would simply
> branches from v3-devel to create a v3-3 branch for release.
> All coders simply work on the v3-devel branch and never
> have to worry about branching again. To which Guenther
> gd: +1 on v3-devel
> The side effect of this model (release every 6 months and
> increment the minor revision number) is that all micro
> releases (3.X.y where y is the micro release) are strictly
> bug fix releases and no more letter releases. To this
> one point, Simo posted:
> idra: I love anyone that agrees on dropping letters :-)
> And clearly using the trunk & release model, we could
> potentially drop the -stable branch al together since
> anything checked into the v3-X release branch is required
> to already be "stable".
> The executive summary of this is that
> A. Developers no longer have to worry about changing
> branches after release
> B. The release manager no long has to cherry-pick fixes
> but still has a high degree of confidence in the release
> C. No one is blocked waiting for a "pull" to the release
> Hope this makes more sense to people now. No more branching
> changes right now. Just work on v3-3-test.
> cheers, jerry
Samba ------- http://www.samba.org
Likewise Software --------- http://www.likewisesoftware.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----