Next focus: PROCESS
foobar
foo at bar.com
Mon Dec 17 09:35:28 PST 2012
On Sunday, 16 December 2012 at 23:18:20 UTC, Jonathan M Davis
wrote:
> On Sunday, December 16, 2012 11:23:57 Andrei Alexandrescu wrote:
>> Right now we're using a tagging system for releases, implying
>> releases
>> are just snapshots of a continuum. But what we need is e.g. to
>> be able
>> to patch 2.065 to fix a bug for a client who can't upgrade
>> right now.
>> That means one branch per release.
>
> Well, you can still do that. You just create a branch from the
> tag when you
> need a branch. You don't have to branch from the latest. You
> can branch from
> any point on the tree, and tags provide a good marker for
> points to branch if
> you need to.
>
> Then the official release is still clearly tagged, but you can
> have branches
> based off it when you need it. It also avoids some minor
> overhead when patching
> releases is rare. My main concern though would be that the
> actual release
> needs to be clearly marked separately from any patches, so it
> pretty much
> requires a tag regardless of what you do with branches.
>
> What I would have expected that we do (though I haven't read
> through most of
> this thread or the wiki yet, so I don't know what's being
> proposed) would be
> to branch when we do beta, and that branch would be what would
> ultimately end
> up where we release from, with a tag on the commit which was
> the actual
> release. If further commits were made for specific clients
> after the release,
> then either you'd make a branch from that which was specific to
> that client, or
> you'd put them on the same branch, where'd they'd be after the
> tag for the
> release and wouldn't affect it.
>
> - Jonathan M Davis
Precisely. Thank you.
More information about the Digitalmars-d
mailing list