From: Chad Walstrom <chewie@wookimus.net>
To: help-gnats@gnu.org
Subject: CVS Branching and Merging
Date: Thu, 17 Jun 2004 16:48:00 -0000 [thread overview]
Message-ID: <20040615204615.GH19638@wookimus.net> (raw)
In-Reply-To: <20040615192846.GG19638@wookimus.net>
[-- Attachment #1.1: Type: text/plain, Size: 1590 bytes --]
Chad Walstrom wrote:
> As far as a timeline, I would like to start preparing a 4.1
> pre-release ASAP. There have been some CVS updates since the original
> 4.0 release, and it's a good time mark the codebase before branching
> off for the big changes in 4.2 and 5.0.
Let me rephrase that. We should probably branch releases and leave the
trunk as the development branch. In which case, we tag the trunk for
the 4.1 release as release_4_1, then create the maintenance branch as
release_4_1_branch. Patch releases to the 4.1 series would then be
tagged from that branch: release_4_1_1, etc.
We don't need to get carried away with judicious branching, but if you
feel comfortable using a branch to work on feature enhancements, please
feel free to do so. Let's leave the trunk for merging. For example,
Mel is planning big changes, so perhaps he branches off the trunk as
{featurename|author}_{revision-branching-from}_dev
And, when you're ready to merge to the trunk, merge from the trunk to
get the updates and tag (with '_merge') after conflicts are resolved.
Then whoever is in charge of merging to the trunk will pull from that
tag. Once merged, we can tag the target trunk/branch with a "_merged"
tag.
Ideas? Overkill?
I know CVS operations to savannah are a bit slow, but it's workable.
What do you all think of judicious tagging? i.e. Tagging the
merge-points of bug fixes or feature additions?
--
Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats
next prev parent reply other threads:[~2004-06-15 20:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-17 9:24 The TODO list and planning a release schedule Chad Walstrom
2004-06-17 16:48 ` Chad Walstrom [this message]
2004-06-20 16:43 ` Mel Hatzis
2004-06-20 17:06 ` Chad Walstrom
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=20040615204615.GH19638@wookimus.net \
--to=chewie@wookimus.net \
--cc=help-gnats@gnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).