25 Jun
2018
25 Jun
'18
10:20 p.m.
Hi Jim,
On Mon, 25 Jun 2018, Jim Dummett via DCPomatic wrote:
Hi Carl.
I'm just wondering how/when you go about merging commits from the test
version into stable branch?
It's a fairly ill-defined procedure. At the moment, if some commit either
1. probably fixes a nasty bug with no side-effects, or
2. almost certainly fixes a minor bug with no side-effects
I will put it into the stable branch. So far I haven't added many (or
any) feature requests into stable, but then
For example, a feature request I made
(https://dcpomatic.com/mantis/view.php?id=1284) was implemented in test
version 2.13.19. Since then, stable 2.12.6 has been released but does
not contain this commit.
this is a fairly risk-free feature addition to a area of the code (the CLI
client) which is not very much used, so I could be persuaded to put it
into master ;)
Stable releases since 2.12.2 are bug fix releases.
However, what
confuses me is that there are many more bug fixes which have been
committed to the test branch. So there's obviously some criteria for
what makes it through to stable and what doesn't.
Some of the test branch bug fixes are either
1. not certain to fix the bug, or
2. deep or complicated or in some way more likely to cause other breakages
If you can be bothered, can you explain the release
strategy a little
bit? And do you have a rough timeline of when the next stable release is
likely to be?
At the moment the timeline is really just putting a finger in the air and
seeing how many commits there are to the release branch since the last
release. I'm happy to firm this up if it would help people.
Just asking as I'm planning ahead to an upcoming
festival and wondering
what version to settle on.
OK I'm fine with adding your --config patch to master and making 2.12.8
(2.12.7 has already been and gone) if that helps.
All the best,
Carl