The `development` branch on our main JMRI/JMRI GitHub repository has now been merged back into the `master` branch.
Please check out the `master` branch to get the current HEAD of development. When you want to make a PR, please target the `master` branch. Both of these should be the defaults.
On the other hand, if you want to make a correction specifically to an earlier release, i.e. production release 4.18, please check out the corresponding `v4.18` tag and branch from there.
On Jan 1, 2020, at 7:15 PM, Bob Jacobsen via Groups.Io <email@example.com> wrote:
Mostly because we said we’d wait a couple weeks to see if we needed a 4.18.1, and 4.18 itself got out late.
I can go ahead and pull everything back now if that’s what people want. Then, if there is a problem that requires a 4.18.1, it’ll be up to whoever’s fixing it to start at the right place. It’ll be interested to see how that goes.
For the sake of definiteness, let’s say that I’ll do that merge back in 16 hours from now if nobody objects. I’m not sure that’s long enough for people to read email and see this at this time of year, but I don’t want to make it harder for you or other people to work.
As to what to do how: I have no idea why your IDE has trouble with this, but you could try using the command line.
(use your IDE to create a new branch you want to work on from i.e. master)
(quit the IDE)
(switch to the JMRI program directory)
git fetch origin
git merge origin/development
That merges the `development` branch onto your working branch, so all the contents should then be there.
On Jan 1, 2020, at 7:06 PM, Dan Boudreau <daboudreau@...> wrote:--
So why is merging to master still locked? I just tried to synch up with all of my changes, and master doesn't have my latest that was part of 19.1.
Tried pulling the development branch, and no luck so far in getting my IDE to work with that branch.
Not sure how or what to do.
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Bob Jacobsen
Sent: Wednesday, January 01, 2020 9:58 PM
Subject: Re: [jmri-developers] Adding a development branch on GitHub
This is basically what we’ve been doing. Instead of single permanent release
branch, there are permanent tags, but we could certainly keep the branch
What it doesn’t deal with is people starting their last-minute changes from the
wrong place. Nobody else but me seems to think that’s an issue now, and so I’ll
just let that go.
On Jan 1, 2020, at 1:13 PM, Dan Boudreau <daboudreau@...>wrote:
permanent release branch.
First, Happy New Year to all.
I really like the master being the so called development branch, and having a
make my synchs and commits continuously, and can ignore the release cycle and
Here's the features that I see:
1. Unless I have a bug that needs to be fixed at the end of a release cycle, I can
the release branch.
way we've been accustomed to.
2. Using master as development means we continue to work with git in the
bug that I need to address during the end of the release cycle, I synch up the
3. Master doesn't get frozen for the production release.
4. I can set up a permanent release branch once in my IDE. Now if there's a
release branch, and make my bug fix to that branch. I consider this an exception
to my work flow, and unless the bug is nasty, I can again ignore the release
branch and just wait to fix the bug in the next test release.
release. Now if we want to create an incremental fix to the production release
5. The release branch will exist for many weeks or months after the production
we can do that very easily.
up with the development branch after "master" was frozen. That changes my
What I didn't like with the last "development" branch, is that I needed to synch
normal work flow, and IMO, makes it harder for new developers, and me.
get pushed to the development "master" branch? Or do I need to commit a bug
My only question is if I commit a bug fix to the release branch, will it eventually
fix to both. I hope not. My hope is that a bug PR to the release branch would
eventually get to the master branch. I'm not sure how this would work or the
timing for synchronizing master with the release branch.