cURL / Mailing Lists / curl-library / Single Mail

curl-library

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

From: Michael Osipov <1983-01-06_at_gmx.net>
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)...

README.md

>> 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.

Michael
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-04-27