Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 24 Jun 2010 09:14:45 -0400

Hi,

I completely agree with Andrew on the approach and the criteria.

What's the plan for 3.15, i.e. for releasing a 3.15.0 preview of our

coming attractions?

Am I right assuming that there will not be another scheduled 3.14

release after 3.14.12? (Except for maybe a bug fix bundle...)

My thoughts on the dynamic array branch decision:

For some installations the static array issue causes considerable pain.

These places would have a high interest in getting this feature.

Looking at the changes I see a certain chance that this feature has side

effects that are yet to be found.

We need something "sexy" in 3.15 to make people try and take it for a

test drive.

If we manage to get out 3.15.0 this summer, I would like to see dynamic

arrays in there. If 3.15.0 means next year, it should go into 3.14.12.

Just my 2 cents....
Ralph

On Wed 23 Jun 2010 18:43:45 Andrew Johnson wrote:

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System