We currently have over 20 development branches of Base on Launchpad, 8 of
which have approvable merge proposals. I see some of them as being
appropriate for a 3.14.12 release, but others will have to go into 3.15.
Before discussing individual branches though, I want to talk about how we
should distinguish and decide between the two. The 3.14 series is very widely
used now, so upgrading to a new point release within the series should be a
I hope no one is going to object to the idea that anything requiring major
changes to existing IOC database applications or support modules should only
be made in a major release, 3.15 (or later). I also want branches like
Marty's process-get work and my compiled-dbd that involve some fairly major
internal redevelopment to go into 3.15, even if they are backwards compatible.
If I understand Jeff's position correctly (correct me if I'm wrong Jeff) he
says that minor releases should only contain bug fixes and no new features.
IMHO though over the last few years that would have prevented the introduction
of many new features to Base that have been successfully included without
breaking backwards compatibility, at a time when we would not have been able
to create a new major release due to partially-implemented features on the CVS
My position is that a development should be acceptable into a minor release if
it is not likely to break existing IOC database applications and it does not
require major changes to existing C code (and any missing C or DBD file
changes get reported at compile- or link-time). Any development that changes
the meaning or use of an existing record field (other than adding new non-
default options) would have to wait for the next major release. Where a
feature is currently broken and effectively unusable those rules can be
relaxed when fixing it in a minor release though.
Applying those principles to the current crop of merge proposals, I make the
following suggestions for merge targets (assuming they all pass the code
I could probably be persuaded either way on the dynamic-array branch.
The best FOSS code is written to be read by other humans -- Harald Welte
- RE: Merges: 3.14.12 vs 3.15 nick.rees
- Re: Merges: 3.14.12 vs 3.15 Ralph Lange
- RE: Merges: 3.14.12 vs 3.15 Davidsaver, Michael
- RE: Merges: 3.14.12 vs 3.15 Jeff Hill
- Navigate by Date:
RE: [Merge] lp:~michael-abbott/epics-base/dynamic-array intolp:epics-base Michael Abbott
RE: [Merge] lp:~michael-abbott/epics-base/dynamic-array intolp:epics-base nick.rees
- Navigate by Thread:
Re: [Merge] lp:~ralph-lange/epics-base/fix-cpp-keywords into lp:epics-base Michael Abbott
RE: Merges: 3.14.12 vs 3.15 nick.rees