Wow, I'm elevated to a whole department! ;-) I wish I had the clones to make it 
true!

If the scripts are in git on code then Geert or I can update them as needed 
when we shift branches.

Regards,
John Ralls

> On Nov 14, 2022, at 8:26 AM, Derek Atkins <de...@ihtfp.com> wrote:
> 
> 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@gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
>> 
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
> 
> 
> -- 
>       Derek Atkins                 617-623-3745
>       de...@ihtfp.com             www.ihtfp.com
>       Computer and Internet Security Consultant
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to