'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/
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,
'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:
>
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
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 t
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
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 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
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 does
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.
>
> Ju
> 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
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 defau
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 sl
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
__
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.o
26 matches
Mail list logo
