[GNC-dev] Git branches

[john]

I guess we could do that as long as we continue the no-backports policy, but it's something you argued against when we started using git-flow a few years ago.

But what about the opposite approach, having only one permanent branch and no major releases? Instead of 5.0 next spring we'll release 2023.1 and the spring after that 2024.1, with .2 in June, .3 in September, and .4 in December every year? Major changes, like c++options, get merged when ready; we might do a beta release (e.g. 2023.2beta) a month before a release with a major change to get better user testing. We'd have to work out policies for API and schema changes because it would blow up the file upgrade path for users who've skipped some releases. There's a very dense exposition on this pattern at http://dymitruk.com/blog/2012/02/05/branch-per-feature/.

Regards,
John Ralls




> On Nov 14, 2022, at 8:17 AM, Geert Janssens <geert.gnucash at 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 at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
>