EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Merges: 3.14.12 vs 3.15
From: "Davidsaver, Michael" <[email protected]>
To: "Andrew Johnson" <[email protected]>, "Core-Talk" <[email protected]>
Date: Thu, 24 Jun 2010 15:27:58 -0400
Andrew,

A question about major changes.  I recently did another iteration on my Cmake build system replacement branch.

https://code.launchpad.net/~mdavidsaver/epics-base/cmake

This work would not be appropriate for 3.14.12, but very likely won't be ready for 3.15.0.  Would you consider a major change like this for 3.15.x, or would it wait for 3.16.0 (in ~2018).  If your answer is 3.16 then I will abandon it since carrying it for ~8 years is not practical.


Michael


> -----Original Message-----
> From: [email protected] [mailto:core-talk-
> [email protected]] On Behalf Of Andrew Johnson
> Sent: Wednesday, June 23, 2010 6:44 PM
> To: Core-Talk
> Subject: Merges: 3.14.12 vs 3.15
> 
> 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



References:
Merges: 3.14.12 vs 3.15 Andrew Johnson

Navigate by Date:
Prev: RE: [Merge] lp:~michael-abbott/epics-base/dynamic-array intolp:epics-base Jeff Hill
Next: RE: Merges: 3.14.12 vs 3.15 Jeff Hill
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Merges: 3.14.12 vs 3.15 Ralph Lange
Next: RE: Merges: 3.14.12 vs 3.15 Jeff Hill
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·