[GNC-dev] Git branches

[Derek Atkins]

I have no objection to changing branch names.

Just keep in mind that several build scripts depend on the branch names,
so if they change once, that's fine, but if they are constantly changing
(e.g. 4.x, 5.x, 4.99, 6.x, etc) then we may need to rework the scripts so
I don't have to coordinate with release-engineering when a new branch gets
created.  (This dev-docs, etc).

-derek

On Mon, November 14, 2022 11:17 am, Geert Janssens wrote:
> This had been brewing in my mind as well, so thanks for bringing this up.
>
> When I considered alternative branch names I initially thought of "stable"
> vs "development"
> or "devel" with an optional "unstable" at times of pre-releases.
>
> However when thinking this through some more I started wondering whether
> we really
> should limit ourselves to just two (or three) branch names.
>
> We could also name our branches "4.x", "5.x" and so on to indicate the
> release series this
> branch is for. At some point we just stop using the older branches. We can
> choose to drop
> them or just leave them in the git history as it suits is best.
>
> Both naming schemes have advantages and drawbacks. I like the direct
> relationship
> between branch name and releases that will be on it for the latter scheme.
> Although I admit
> this relationship doesn't hold for the pre-releases, unless we make that a
> separate branch for
> those like eg "4.9xx".
>
> Regards,
>
> Geert
>
> Op zondag 13 november 2022 21:40:14 CET schreef john:
>> Since Geert brought up our relationship with Github I thought it timely
>> to
>> start a discussion about a related trend: The name of the git
>> repository's
>> primary branches. There's an ongoing effort in the software development
>> community for the last 25-30 years or so to remove the terms master and
>> slave; originally when used together (as in processes) but more recently
>> when used alone. This recently includes the name of the primary branch
>> in a
>> git repository. The Gitlab folks have a nice summary at
>> https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/.
>>
>> 'Master' was the standard when we started using git 10 years ago and so
>> we
>> adopted it and still use it. Aside from the cultural sensitivity issues
>> (primarily in the United States because of our unfortunate history with
>> forced importation and enslavement of Africans) it has proved to be a
>> bit
>> confusing to new contributors.
>>
>> The new standard default is 'main'. I think that would be fine for
>> htdocs
>> where we have master and beta: Main would better express that that's the
>> branch that you see when you visit https://www.gnucash.org
>> <https://www.gnucash.org/>. The gnucash-on-foo repositories for the
>> build
>> processes have only master branches so it doesn't really matter what the
>> branch is called.
>>
>> I don't think 'main' is the right name for gnucash or gnucash-docs
>> because
>> it does nothing about the confusion factor. Note that the default branch
>> on
>> those two is maint but we still use master for the next major release's
>> branch. The most expressive titles would be current-major-release and
>> next-major-release but they're a bit wordy; OTOH just current (or curr)
>> and
>> next leave a new contributor to ask current and next what? maint is
>> concise
>> and not terrible for a branch that gets only bug fixes and small
>> features.
>> Lots of generic names for the next-major-release branch (future, devel
>> or
>> development, major-change) come to mind but I'm not sure that any of
>> them
>> clearly express the intent of the branch.
>>
>> Comments?
>>
>> Regards,
>> John Ralls
>>
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant