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
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
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 existin
> 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
>
>
>
>
> -- 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 de
> 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-deve
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 2
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
> ne
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
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,
J
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 bring
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
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 wonderin
13 matches
Mail list logo
