Hello LinuxCNC Developers! At Moses' request I have created a new
branch named '2.8' and made some associated updates to the buildbot, in
preparation for the next LinuxCNC release.
2.8.0 has *NOT* been released. The creation of the 2.8 branch is a step
in that direction, but we're not at the destination yet. Our 2.8
Release Manager, Moses, will inform us when the release happens.
This email describes how to use this new 2.8 branch, in conjunction with
the 2.7 stable branch and the master branch, to do effective work on
LinuxCNC.
The main thing to know is that our project uses the "merging upwards"
work flow: https://git-scm.com/docs/gitworkflows#_merging_upwards
That whole page is worth reading, but the TL;DR is:
Always commit your fixes to the oldest supported branch that
requires them. Then (periodically) merge the integration branches
upwards into each other.
Let's unpack that a bit. What does "oldest supported branch" mean, and
what does "merge the branches upwards into each other" mean?
"Supported branches" in this case means official, long-lived branches;
for us that is "2.7", "2.8", and "master" (aka "2.9~pre"). The "oldest"
supported branch is of course 2.7. 2.8 is the next newer branch, and
master is the newest. So if you're fixing a bug, and you're feeling
your oats, our users will benefit if you do a little bit of extra work
to identify the "oldest supported branch" that has that bug, and apply
the fix there.
"Merge upwards" means: after fixing a bug in that old branch, merge it
into the next newer branch. Then merge *that* branch into *it's* next
newer branch, and so on until you get to master. So 2.7 merges into
2.8, and 2.8 merges into master. This will ensure that the bug gets
fixed in *all* important long-lived branches, and we avoid regressions.
This "merging upwards" workflow applies to bug fixes only. Other types
of work are handled differently depending on the situation.
In general, changes that don't break existing configurations and don't
risk destabilizing working setups can go in stable branches.
Changes that require modifications to existing working configurations
(the Joints/Axes work is a great example) must *never* go in a stable
branch! Changes that mess with deep dark internals, that might change
or break machine behavior in unexpected ways must *never* go in a stable
branch! That stuff belongs in master. (I learned this the hard way in
2.7.5.)
* Docs improvements can often but not always be treated like bug fixes.
* New drivers, components, and UIs can often but not always be added to
a stable branch, since they often don't affect working configurations.
* New features are scary! They belong in master!
* If in doubt, talk to the stable branch Release Manager (that's me for
2.7 and Moses McKnight for 2.8), and talk to the other devs on the
mailing list.
That's it. Thanks for reading to the end.
--
Sebastian Kuzminsky
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
