Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 23 Jun 2010 17:43:45 -0500

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 
straight-forward process.

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 
main trunk.

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 
review):

            lp:~khkim/epics-base/alarm-filter       3.14.12
      lp:~ralph-lange/epics-base/ca-over-tcp        3.14.12
  lp:~ronaldo-mercado/epics-base/capr               3.14.12
      lp:~mdavidsaver/epics-base/devlib-cleanup     3.14.12
   lp:~michael-abbott/epics-base/dynamic-array      3.15
      lp:~dirk.zimoch/epics-base/fix-aai-and-aao    3.14.12
      lp:~dirk.zimoch/epics-base/named-soft-events  3.15
      lp:~dirk.zimoch/epics-base/non-val-attributes 3.15

I could probably be persuaded either way on the dynamic-array branch.

Comments please...

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System