cURL / Mailing Lists / curl-library / Single Mail


Re: A case for a branch and follow-up release?

From: Michael Osipov <>
Date: Mon, 27 Apr 2015 22:45:16 +0200

Am 2015-04-27 um 22:34 schrieb Daniel Stenberg:
> On Mon, 27 Apr 2015, Michael Osipov wrote:
>>> 7_42 is for the 7.42 series, starting from 7.42.0. I don't think the
>>> branch name is terribly important. Is it? How would you like it
>>> called ? 'branch-7.42.x' ?
>> Given that it is already a branch, I consider the prefix 'branch-' as
>> redundant, I would stick to '7.42.x' or 'curl-7.42.x'.
> But that could be considered confusingly similar to our tag names.
> They're in the "curl-7_42_0" format...

I don't think so, the *x* says pretty much it. Most people are familiar
with semver.

>> I think a name has to be clear and easy recognizable for everyone
>> cloning from GitHub.
> We need to explain somewhere what the branch is for whatever we call
> them though. Or if we don't, the pattern will be quite easy to detect
> anyway (at least once we create more patch branches than the single
> existing one)...

>> Consider Isaac Boukris would like to work on GH-232 from a stable
>> branch without hindering anyone else.
> I would still recommend working rebased on the master. It isn't like
> we're doing massive and ground-breaking changes very often that would
> ruin it for contributors.
> I want pull requests or patches based on master when time is ripe for
> review.

That is OK at the end, during development -- I would rely on the stable
branch and only when my change is stable, I would integrate master into
my branch and issue a PR.

>> He would simply branch off 7.42.x (stable), call the new brach GH-232
>> which is a feature branch. This naming pattern would be directly
>> visible for everyone fetching from bagder/curl and especially when he
>> is ready to merge his changes back to master. We have a
>> selfexplanatory Git log.
> I prefer a clean and linear git history as long as we're this small and
> have this easy development process.
> Let's not overdo it.

That was just an example based on the new possibilities you would have.
You can always perform a rebase which is fine for a linear history.

List admin:
Received on 2015-04-27