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: "Jeff Hill" <[email protected]>
To: "'Andrew Johnson'" <[email protected]>, "'Core-Talk'" <[email protected]>
Date: Thu, 24 Jun 2010 14:16:25 -0600
> 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.

Yep, that’s still my perspective. From my viewpoint we should be especially careful to not mix up patches with new features. For two reasons. One, we don’t ever want a situation where the user looses confidence about installing patches because they might introduce new bugs. Second, we work on a special type of software which people depend on. A selling point of EPICS is that we have maintained a certain level of quality in the past. Sometime a conservative approach is necessary.

Maybe the solution is to have three independent release series: maybe we should have the stable production release, the near term features release, and the evolution release. With that approach we can have an independent release series on all three versions simultaneously. With this approach it needs to be very clear to everyone involved where we are headed. That is, it needs to be very clear that day-to-day support of the production release will after some longer period of time go away, the near term release will be eventually declared to be the production release, and the evolution release will eventually become the near-term feature release. What do you think? 

Lastly, I have to say that its disturbing that my new server with server based event filtering isn't even discussed as an option for the list for any release. I have been working very hard to get this finished. Yes, its new code, but if regression tests are reasonably exhaustive and we are clear about how and where new releases should be used then I don't see a problem.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA


> -----Original Message-----
> From: [email protected] [mailto:core-talk-
> [email protected]] On Behalf Of Andrew Johnson
> Sent: Wednesday, June 23, 2010 4: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



Replies:
Re: Merges: 3.14.12 vs 3.15 Ralph Lange
Re: Merges: 3.14.12 vs 3.15 Andrew Johnson
References:
Merges: 3.14.12 vs 3.15 Andrew Johnson

Navigate by Date:
Prev: RE: Merges: 3.14.12 vs 3.15 Davidsaver, Michael
Next: Re: Merges: 3.14.12 vs 3.15 Ralph Lange
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 Davidsaver, Michael
Next: Re: Merges: 3.14.12 vs 3.15 Ralph Lange
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 ·