From: Alexander Litvinov <litvinov2004@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: Question: next, master and pu branches
Date: Fri, 2 Feb 2007 12:52:13 +0600 [thread overview]
Message-ID: <200702021252.14076.litvinov2004@gmail.com> (raw)
In-Reply-To: <7v8xfhksg0.fsf@assigned-by-dhcp.cox.net>
> I think what you are looking for is how my 'maint' and 'master'
> branches are maintained; 'maint' corresponds to your "stable
> release" while 'master' corresponds to your "develment branch".
>
> When a stable release is cut, 'maint' is forked from there.
>
> Truly obvious corrections will be applied on top of the tip of
> 'maint' directly, while if there are any doubt about a proposed
> change I might fork a topic off of the tip of 'maint' and cook
> the fix for a while until I finally merge it to 'maint'. This
> way, 'maint' will be "bugfix only since the last release".
>
> The tip of 'maint' will be merged into 'master', from time to
> time, to make sure that all fixes will be in 'master'.
>
> When it is time for a new release to be cut, I'd make sure that
> the tip of 'maint' is merged into 'master' (it usually is) and
> then the tip of the 'master' is tagged to be released. After a
> release is made, I could have two maintenance branches (one that
> continues on top of the old codebase, another that fixes the new
> release). A fix that can apply to both codebases will be
> applied to the maintenance branch for the old release and then
> its tip can be pulled into the maintenance branch for the new
> release and then its tip can further be merged into the
> development branch.
>
> At some point, the codebases for the older release and the
> current release become diverged enough that merging could become
> inpractical (the same bug may need different fix if the
> infrastracture has become different); you would need to bite the
> bullet and fix it twice (i.e. differently).
Thanks for detailed description. As a cunclusion I would like to say: all bug
fixes are made in the stable branch and then stable branch will be merged to
development branch. That is easy !
next prev parent reply other threads:[~2007-02-02 6:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-02 5:42 Question: next, master and pu branches Alexander Litvinov
2007-02-02 6:00 ` Shawn O. Pearce
2007-02-02 6:54 ` Alexander Litvinov
2007-02-02 6:57 ` Shawn O. Pearce
2007-02-02 6:02 ` Junio C Hamano
2007-02-02 6:52 ` Alexander Litvinov [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-02-02 5:41 Alexander Litvinov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200702021252.14076.litvinov2004@gmail.com \
--to=litvinov2004@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.