Re: [GNC-dev] Git branches

[Adrien Monteleone]

'next' is a good one. It is unambiguous, and unlikely to get auto-corrected.

Regards,
Adrien

On 3/24/23 10:02 AM, Chris Graves wrote:

Or perhaps, cur(rent) and next.


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

Re: [GNC-dev] Git branches

[Chris Graves]

Or perhaps, cur(rent) and next.

> On Mar 24, 2023, at 7:54 AM, Alex Aycinena  wrote:
> 
> 'Stable' seems weird because it is where all the big changes will go in the
> future. How about 'Primary' for what is now 'Master' and then you change
> 'Maint' as you suggest?
> 
> Alex
> 
> On Thu, Mar 23, 2023 at 7:18 PM Brian Rater  wrote:
> 
>> Future?
>> 
>> On Thu, Mar 23, 2023 at 8:57 PM John Ralls  wrote:
>> 
>>> We're 3 days away from releasing 5.0 and so 4 days away from shuffling
>>> the branches. Absent any objections I intend to rename the current "master"
>>> to "stable" and make it the default branch on Github. Bugfixes and
>>> minor-to-medium features can go to stable. I'll rename maint to
>>> archive/maint so that nobody is tempted to commit to it any more.
>>> 
>>> We have a little time to discuss the medium-to-major branch name. We
>>> don't need it until someone has a medium-to-major feature branch to merge
>>> in. While "unstable" is the logical opposite of "stable" it's also shares
>>> too many letters, though unlike "main" and "maint" at least the extra
>>> letters are upfront so you're less likely to get bitten by completion. I'm
>>> inclined toward "development". "devel" would be OK if spell-check didn't
>>> keep trying to turn it into "level".
>>> 
>>> Regards,
>>> John Ralls
>>> 
>>> 
 On Nov 18, 2022, at 9:08 AM, john  wrote:
 
 We could pinch from Debian and use stable, testing, and unstable, where
>>> testing is the alpha/beta pre-major-release weeklies.
 
 Regards,
 John Ralls
 
 
> On Nov 18, 2022, at 7:55 AM, Geert Janssens <
>>> geert.gnuc...@kobaltwit.be> wrote:
> 
> I'm fine with just doing the simple name change for our two primary
>>> branches as it's the option of least effort.
> 
> I'd rather have a different name than "main" though. It's a bit
>>> ambiguous and like "master" suggesting this branch is somehow more
>>> important than the other long-term branch "maint". I'd rather have names
>>> that help guide contributors to the right branch to work from. I don't
>>> think there's a silver bullet here though, but some names may give more of
>>> a hint than others. Some suggestions:
> 
> * "current" vs "future" as shorthands for "current-release-series" or
>>> "future-release-series"
> * "maintenance" ("maint") vs "development" ("devel")
> * "stable" vs "development"
> 
> That said, I'm also very interested in the single branch model as
>>> alternative. Discussion on that is for another message.
> 
> Regards,
> 
> Geert
> 
> Op maandag 14 november 2022 20:59:26 CET schreef john:
>>> On Nov 14, 2022, at 11:11 AM, Alex Aycinena >>> 
>>> wrote:
>>> 
>>> how about a simple change, like calling it 'main' rather than
>>> 'master' and keeping the existing pattern for branches.
>> 
>> That would be OK as long as long as the two names aren't similar.
>>> main and
>> stable would be OK; with main and maint one is far too likely to do
>> something to the wrong branch.
>> 
>> 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

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

Re: [GNC-dev] Git branches

[Alex Aycinena]

'Stable' seems weird because it is where all the big changes will go in the
future. How about 'Primary' for what is now 'Master' and then you change
'Maint' as you suggest?

Alex

On Thu, Mar 23, 2023 at 7:18 PM Brian Rater  wrote:

> Future?
>
> On Thu, Mar 23, 2023 at 8:57 PM John Ralls  wrote:
>
>> We're 3 days away from releasing 5.0 and so 4 days away from shuffling
>> the branches. Absent any objections I intend to rename the current "master"
>> to "stable" and make it the default branch on Github. Bugfixes and
>> minor-to-medium features can go to stable. I'll rename maint to
>> archive/maint so that nobody is tempted to commit to it any more.
>>
>> We have a little time to discuss the medium-to-major branch name. We
>> don't need it until someone has a medium-to-major feature branch to merge
>> in. While "unstable" is the logical opposite of "stable" it's also shares
>> too many letters, though unlike "main" and "maint" at least the extra
>> letters are upfront so you're less likely to get bitten by completion. I'm
>> inclined toward "development". "devel" would be OK if spell-check didn't
>> keep trying to turn it into "level".
>>
>> Regards,
>> John Ralls
>>
>>
>> > On Nov 18, 2022, at 9:08 AM, john  wrote:
>> >
>> > We could pinch from Debian and use stable, testing, and unstable, where
>> testing is the alpha/beta pre-major-release weeklies.
>> >
>> > Regards,
>> > John Ralls
>> >
>> >
>> >> On Nov 18, 2022, at 7:55 AM, Geert Janssens <
>> geert.gnuc...@kobaltwit.be> wrote:
>> >>
>> >> I'm fine with just doing the simple name change for our two primary
>> branches as it's the option of least effort.
>> >>
>> >> I'd rather have a different name than "main" though. It's a bit
>> ambiguous and like "master" suggesting this branch is somehow more
>> important than the other long-term branch "maint". I'd rather have names
>> that help guide contributors to the right branch to work from. I don't
>> think there's a silver bullet here though, but some names may give more of
>> a hint than others. Some suggestions:
>> >>
>> >> * "current" vs "future" as shorthands for "current-release-series" or
>> "future-release-series"
>> >> * "maintenance" ("maint") vs "development" ("devel")
>> >> * "stable" vs "development"
>> >>
>> >> That said, I'm also very interested in the single branch model as
>> alternative. Discussion on that is for another message.
>> >>
>> >> Regards,
>> >>
>> >> Geert
>> >>
>> >> Op maandag 14 november 2022 20:59:26 CET schreef john:
>>  On Nov 14, 2022, at 11:11 AM, Alex Aycinena > >
>>  wrote:
>> 
>>  how about a simple change, like calling it 'main' rather than
>>  'master' and keeping the existing pattern for branches.
>> >>>
>> >>> That would be OK as long as long as the two names aren't similar.
>> main and
>> >>> stable would be OK; with main and maint one is far too likely to do
>> >>> something to the wrong branch.
>> >>>
>> >>> 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

Re: [GNC-dev] Git branches

[Brian Rater]

Future?

On Thu, Mar 23, 2023 at 8:57 PM John Ralls  wrote:

> We're 3 days away from releasing 5.0 and so 4 days away from shuffling the
> branches. Absent any objections I intend to rename the current "master" to
> "stable" and make it the default branch on Github. Bugfixes and
> minor-to-medium features can go to stable. I'll rename maint to
> archive/maint so that nobody is tempted to commit to it any more.
>
> We have a little time to discuss the medium-to-major branch name. We don't
> need it until someone has a medium-to-major feature branch to merge in.
> While "unstable" is the logical opposite of "stable" it's also shares too
> many letters, though unlike "main" and "maint" at least the extra letters
> are upfront so you're less likely to get bitten by completion. I'm inclined
> toward "development". "devel" would be OK if spell-check didn't keep trying
> to turn it into "level".
>
> Regards,
> John Ralls
>
>
> > On Nov 18, 2022, at 9:08 AM, john  wrote:
> >
> > We could pinch from Debian and use stable, testing, and unstable, where
> testing is the alpha/beta pre-major-release weeklies.
> >
> > Regards,
> > John Ralls
> >
> >
> >> On Nov 18, 2022, at 7:55 AM, Geert Janssens 
> wrote:
> >>
> >> I'm fine with just doing the simple name change for our two primary
> branches as it's the option of least effort.
> >>
> >> I'd rather have a different name than "main" though. It's a bit
> ambiguous and like "master" suggesting this branch is somehow more
> important than the other long-term branch "maint". I'd rather have names
> that help guide contributors to the right branch to work from. I don't
> think there's a silver bullet here though, but some names may give more of
> a hint than others. Some suggestions:
> >>
> >> * "current" vs "future" as shorthands for "current-release-series" or
> "future-release-series"
> >> * "maintenance" ("maint") vs "development" ("devel")
> >> * "stable" vs "development"
> >>
> >> That said, I'm also very interested in the single branch model as
> alternative. Discussion on that is for another message.
> >>
> >> Regards,
> >>
> >> Geert
> >>
> >> Op maandag 14 november 2022 20:59:26 CET schreef john:
>  On Nov 14, 2022, at 11:11 AM, Alex Aycinena 
>  wrote:
> 
>  how about a simple change, like calling it 'main' rather than
>  'master' and keeping the existing pattern for branches.
> >>>
> >>> That would be OK as long as long as the two names aren't similar. main
> and
> >>> stable would be OK; with main and maint one is far too likely to do
> >>> something to the wrong branch.
> >>>
> >>> 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

Re: [GNC-dev] Git branches

[John Ralls]

We're 3 days away from releasing 5.0 and so 4 days away from shuffling the 
branches. Absent any objections I intend to rename the current "master" to 
"stable" and make it the default branch on Github. Bugfixes and minor-to-medium 
features can go to stable. I'll rename maint to archive/maint so that nobody is 
tempted to commit to it any more. 

We have a little time to discuss the medium-to-major branch name. We don't need 
it until someone has a medium-to-major feature branch to merge in. While 
"unstable" is the logical opposite of "stable" it's also shares too many 
letters, though unlike "main" and "maint" at least the extra letters are 
upfront so you're less likely to get bitten by completion. I'm inclined toward 
"development". "devel" would be OK if spell-check didn't keep trying to turn it 
into "level".

Regards,
John Ralls


> On Nov 18, 2022, at 9:08 AM, john  wrote:
> 
> We could pinch from Debian and use stable, testing, and unstable, where 
> testing is the alpha/beta pre-major-release weeklies.
> 
> Regards,
> John Ralls
> 
> 
>> On Nov 18, 2022, at 7:55 AM, Geert Janssens  
>> wrote:
>> 
>> I'm fine with just doing the simple name change for our two primary branches 
>> as it's the option of least effort.
>> 
>> I'd rather have a different name than "main" though. It's a bit ambiguous 
>> and like "master" suggesting this branch is somehow more important than the 
>> other long-term branch "maint". I'd rather have names that help guide 
>> contributors to the right branch to work from. I don't think there's a 
>> silver bullet here though, but some names may give more of a hint than 
>> others. Some suggestions:
>> 
>> * "current" vs "future" as shorthands for "current-release-series" or 
>> "future-release-series"
>> * "maintenance" ("maint") vs "development" ("devel")
>> * "stable" vs "development"
>> 
>> That said, I'm also very interested in the single branch model as 
>> alternative. Discussion on that is for another message.
>> 
>> Regards,
>> 
>> Geert
>> 
>> Op maandag 14 november 2022 20:59:26 CET schreef john:
 On Nov 14, 2022, at 11:11 AM, Alex Aycinena 
 wrote:
 
 how about a simple change, like calling it 'main' rather than
 'master' and keeping the existing pattern for branches.
>>> 
>>> That would be OK as long as long as the two names aren't similar. main and
>>> stable would be OK; with main and maint one is far too likely to do
>>> something to the wrong branch.
>>> 
>>> 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

Re: [GNC-dev] Git branches

[john]

We could pinch from Debian and use stable, testing, and unstable, where testing 
is the alpha/beta pre-major-release weeklies.

Regards,
John Ralls


> On Nov 18, 2022, at 7:55 AM, Geert Janssens  
> wrote:
> 
> I'm fine with just doing the simple name change for our two primary branches 
> as it's the option of least effort.
> 
> I'd rather have a different name than "main" though. It's a bit ambiguous and 
> like "master" suggesting this branch is somehow more important than the other 
> long-term branch "maint". I'd rather have names that help guide contributors 
> to the right branch to work from. I don't think there's a silver bullet here 
> though, but some names may give more of a hint than others. Some suggestions:
> 
> * "current" vs "future" as shorthands for "current-release-series" or 
> "future-release-series"
> * "maintenance" ("maint") vs "development" ("devel")
> * "stable" vs "development"
> 
> That said, I'm also very interested in the single branch model as 
> alternative. Discussion on that is for another message.
> 
> Regards,
> 
> Geert
> 
> Op maandag 14 november 2022 20:59:26 CET schreef john:
> > > On Nov 14, 2022, at 11:11 AM, Alex Aycinena 
> > > wrote:
> > >
> > > how about a simple change, like calling it 'main' rather than
> > > 'master' and keeping the existing pattern for branches.
> >
> > That would be OK as long as long as the two names aren't similar. main and
> > stable would be OK; with main and maint one is far too likely to do
> > something to the wrong branch.
> >
> > 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

Re: [GNC-dev] Git branches

[Geert Janssens]

I'm fine with just doing the simple name change for our two primary branches as 
it's the 
option of least effort.

I'd rather have a different name than "main" though. It's a bit ambiguous and 
like "master" 
suggesting this branch is somehow more important than the other long-term 
branch 
"maint". I'd rather have names that help guide contributors to the right branch 
to work from. 
I don't think there's a silver bullet here though, but some names may give more 
of a hint 
than others. Some suggestions:

* "current" vs "future" as shorthands for "current-release-series" or 
"future-release-series" 
* "maintenance" ("maint") vs "development" ("devel")
* "stable" vs "development"

That said, I'm also very interested in the single branch model as alternative. 
Discussion on 
that is for another message.

Regards,

Geert

Op maandag 14 november 2022 20:59:26 CET schreef john:
> > On Nov 14, 2022, at 11:11 AM, Alex Aycinena 
> > wrote:
> > 
> > how about a simple change, like calling it 'main' rather than
> > 'master' and keeping the existing pattern for branches.
> 
> That would be OK as long as long as the two names aren't similar. main and
> stable would be OK; with main and maint one is far too likely to do
> something to the wrong branch.
> 
> 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

Re: [GNC-dev] Git branches

[john]

I didn't follow completely all of dymitruk's essay either, but it seems clear 
to me that he's working in a much larger team than we are. His suggestion for 
handling merge conflicts was a shared git rerere cache; I understand the 
principle but I'm not completely clear about the implementation. I had the 
impression that  release branches were like feature branches: Used once by the 
release team and discarded, and that his team uses Atlassian's Jira to keep 
track of what branches are merged into each release. He didn't go into a lot of 
detail about how to do it, and absent us adopting Jira I don't think that would 
matter much. Anyway I didn't mean to suggest that we should take up that whole 
rather complicated process; I just thought it a useful outline of the 
single-branch strategy.

Not only do we not do semantic versioning, I don't think we even know how. 
https://en.wikipedia.org/wiki/Software_versioning#Semantic_versioning has a 
brief description that says that you bump the major number if you remove or 
change some existing API, the minor number if you add API, and the patch number 
(which we got rid of with 3.0) for all other changes. That doesn't make any 
sense at all for GnuCash the application, it's for libraries. For GnuCash right 
now it would really just for bindings and maybe only the Guile bindings.

Glib has some nice macros, based somewhat on Apple's Availability Macros, in 
https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gversionmacros.h.in that 
can be used in functions declarations to emit or suppress deprecation warnings 
based on a target version of any Glib-based library. We *could* use those 
directly or we could pinch them and adapt them to however we want to manage 
deprecations. Glib and several other GNOME libraries also have deprecated 
directories, e.g. 
https://gitlab.gnome.org/GNOME/glib/-/tree/main/glib/deprecated that they use 
when they deprecate whole classes.

The SQL backend has that per-table version check and built in update queries to 
update a database when the version changes, but since it doesn't write out a 
new DB on every save it has a much greater need for that feature than does the 
XML backend. There's also GNUCASH_RESAVE_VERSION that's available to indicate 
that the database needs to be purged and rewritten from memory. Fortunately we 
haven't needed to change it. The XML backend does have versions on each 
top-level element. They're all 2.0.0 suggesting that either we haven't been 
very good about updating them when we change something or that the schema is a 
lot more stable than we think it is. From a design standpoint I'm not sure that 
versioning every entry is all that useful considering that everything is 
written out fresh with every save.

Regards,
John Ralls


> On Nov 15, 2022, at 9:25 AM, Geert Janssens  
> wrote:
> 
> Op maandag 14 november 2022 19:59:24 CET schreef 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.
> >
> 
> I don't have a clear memory of what I argued against way back then. It 
> doesn't matter much. In reality we have continued to avoid backporting 
> anyway, which is just fine for the small team that we are.
> 
> > 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/.
> 
> It's actually a branch and release pattern I had been considering but was 
> hesitant to bring up as perhaps to radical. Since you now bring it up for 
> consideration, let's evaluate it after all.
> 
> 1. I like the idea of only a single release branch and all development 
> happening on feature or bugfix branches that get merged into this release 
> branch when ready.
> 
> 2. I also like the idea of dropping distinction between a stable and 
> development series. It would bring improvements to users much faster in 
> general - it will be released when ready, not queued for the next major 
> release (which could be only in 2 years worst case).
> It's a bit what fast moving projects such as webbrowsers currently do.
> 
> 3. Year based release numbering is also very clear. And always gives a 
> reasonable indication of how old a given version of gnucash is.
> 
> 
> On the flip side
> 1. This does do away with semantic versioning completely. But that's the 
> whole point of having only 

Re: [GNC-dev] Git branches

[Geert Janssens]

Op maandag 14 november 2022 19:59:24 CET schreef 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.
> 

I don't have a clear memory of what I argued against way back then. It doesn't 
matter much. 
In reality we have continued to avoid backporting anyway, which is just fine 
for the small 
team that we are.

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

It's actually a branch and release pattern I had been considering but was 
hesitant to bring 
up as perhaps to radical. Since you now bring it up for consideration, let's 
evaluate it after all.

1. I like the idea of only a single release branch and all development 
happening on feature or 
bugfix branches that get merged into this release branch when ready. 

2. I also like the idea of dropping distinction between a stable and 
development series. It 
would bring improvements to users much faster in general - it will be released 
when ready, 
not queued for the next major release (which could be only in 2 years worst 
case).
It's a bit what fast moving projects such as webbrowsers currently do.

3. Year based release numbering is also very clear. And always gives a 
reasonable indication 
of how old a given version of gnucash is.


On the flip side
1. This does do away with semantic versioning completely. But that's the whole 
point of 
having only one release branch. Each release can be a mix of bugfixes and new 
features.
2. I imagine this only works well if newly added code (features or bugfixes 
alike) is well 
tested, implying having tests written for it. And that the existing code base 
is well tested as 
well. While slowly improving, the gnucash code is still not very well covered.

I also read through the dymitruk article you linked to. There are a few other 
elements that 
are not fully clear to me yet:

* he talks about an integration branch. Is that a branch that people continue 
to merge their 
new work in, and that just serves 
a. to discover and resolve merge conflicts early on and
b. to run an integration test suite on
Will this branch ever be cleaned or just merge upon merge be added to it ? I 
have no clear 
example of how such a branch is used really.

* there's a separate release branch. Which can be reset from time to time if 
bad features are 
to be skipped for the most recent release. Resetting a branch seems to conflict 
with 
distributed repositories in my mind. But perhaps this is not a problem if it's 
commonly 
known this a a resettable branch. And no devs except for the release manager 
should really 
check out this branch and then even only while preparing for releases ? It's a 
bit vague to 
me.

* handling merge conflicts and sharing the resolutions seem to be an important 
part of the 
solution. Otherwise these conflicts continue to trip up different devs. There 
was a suggestion 
as to how to do this, but nothing concrete. Something to figure out as well.



As for the API and schema changes, that would indeed require some 
reconsideration. 

I have a few first thoughts, but nothing well structured:

* For API the important change to keep in mind is deprecation. New API won't be 
an issue.  
Do we support function signature changes or should a new function be defined in 
that case ?
Current policy is that we deprecate in a stable series and remove in a future 
major release. 
As our current schedule is a two-year cycle for major releases, we could make 
the policy "a 
deprecated feature/function will be kept around for 2 years, after which it 
will be definitely 
removed". Other durations can be chosen as well, as long as it's clear. So 
consumers of the 
api could at most jump two years ahead from the version they currently use with 
a 
guarantee their own code continues to work. At that point they should do the 
work of 
updating their code to cope with deprecated api.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Git branches

[Adrien Monteleone]

My 2¢:

From a user perspective, I very much like the idea of a year.quarter 
numbering scheme. One need never have to research the age of the release 
they are using. (even those of us who know the cycle)


If non-compatible changes are kept on say, the ".1" or a year-based 
boundary, that would make the upgrade path easy enough to follow.


Regards,
Adrien

On 11/14/22 12:59 PM, john wrote:

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


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

Re: [GNC-dev] Git branches

[David T. via gnucash-devel]

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

Re: [GNC-dev] Git branches

[Alex Aycinena]

Good point! You would have to change both or it would be too easy to make a
mistake.

Alex

On Mon, Nov 14, 2022 at 11:59 AM john  wrote:

>
>
> On Nov 14, 2022, at 11:11 AM, Alex Aycinena 
> wrote:
>
> how about a simple change, like calling it 'main' rather than
> 'master' and keeping the existing pattern for branches.
>
>
> That would be OK as long as long as the two names aren't similar. main and
> stable would be OK; with main and maint one is far too likely to do
> something to the wrong branch.
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Git branches

[john]

> On Nov 14, 2022, at 11:11 AM, Alex Aycinena  wrote:
> 
> how about a simple change, like calling it 'main' rather than
> 'master' and keeping the existing pattern for branches.

That would be OK as long as long as the two names aren't similar. main and 
stable would be OK; with main and maint one is far too likely to do something 
to the wrong branch.

Regards,
John Ralls

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

Re: [GNC-dev] Git branches

[Alex Aycinena]

>
>
>
>
> -- Forwarded message --
> From: Derek Atkins 
> To: Geert Janssens 
> Cc: gnucash-devel 
> Bcc:
> Date: Mon, 14 Nov 2022 11:26:02 -0500
> Subject: Re: [GNC-dev] Git branches
> 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
> >
>
>
Since we don't have a 'slave' branch, 'master' doesn't necessisarily have
that negative connotation. But rather than get into a complicated
discussion, how about a simple change, like calling it 'main' rather than
'master' and keeping the existing pattern for branches.

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

Re: [GNC-dev] Git branches

[john]

> On Nov 14, 2022, at 10:41 AM, Derek Atkins  wrote:
> 
> But no, the scripts are not in git.

That's easily changed.

Regards,
John Ralls

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

Re: [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  
> 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
> > . 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

Re: [GNC-dev] Git branches

[Derek Atkins]

Well, the role has changed people over time.
But no, the scripts are not in git.
-d

On Mon, November 14, 2022 1:30 pm, john wrote:
> 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  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
 . 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
>> 

Re: [GNC-dev] Git branches

[john]

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

Re: [GNC-dev] Git branches

[john]

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

Re: [GNC-dev] Git branches

[David T. via gnucash-devel]

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

Re: [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
>> . 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

Re: [GNC-dev] Git branches

[Geert Janssens]

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

Re: [GNC-dev] Git branches

[list+gnucash]

On 2022-11-13 12:40, john wrote:


...I thought it timely to start a discussion about a related trend: The name of 
the git repository's primary branches

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?


How about "next" and "maint", for "next-major-release" and 
"current-major-release"?


Or maybe "current-maint" instead of "maint".

And by the way, I love how you worded this bit:


...the cultural sensitivity issues (primarily in the United States because of 
our unfortunate history with forced importation and enslavement of Africans)...
I think the forthright words "forced importation and enslavement" are a 
good preemptive rebuttal to the objection that branch naming is just a 
matter of posturing and virtue signalling. There is a real horror that 
it is good to take seriously. Thank you.


Best regards,
 —Jim DeLaHunt

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

[GNC-dev] Git branches

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

Re: [GNC-dev] Git branches

[Jean Laroche]

Awesome! Thanks!
J.

On 7/7/20 3:43 PM, John Ralls wrote:

I just completed the post-4.0 branch shuffle, so maint is 4.0 and should get 
commits for stable release. master is 4.900 and ready for changes leading to 
5.0 in 2-3 years time.

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

[GNC-dev] Git branches

[John Ralls]

I just completed the post-4.0 branch shuffle, so maint is 4.0 and should get 
commits for stable release. master is 4.900 and ready for changes leading to 
5.0 in 2-3 years time.

Regards,
John Ralls

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