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