No problem. I don't profess to be much of an expert on these points. Thanks for replying.
David T. On Nov 14, 2022, 9:23 PM, at 9:23 PM, john <jra...@ceridwen.us> wrote: >David, > >Unfortunately that's ambiguous without explaining that in that >particular context release means major release series. In ordinary >usage the current release is 4.12; it can't get any more commits. The >next release is 4.13 and will release off what we now call the maint >branch. > >Regards, >John Ralls > > >> On Nov 14, 2022, at 10:05 AM, David T. via gnucash-devel ><gnucash-devel@gnucash.org> wrote: >> >> Not that my opinion carries much weight on this, but >"current-release" and "next-release" might be a reasonable set of >options that are less wordy but still clear? >> >> David T. >> >> On Nov 14, 2022, 19:17, at 19:17, Geert Janssens ><geert.gnuc...@kobaltwit.be> 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 >> _______________________________________________ >> 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
