> 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
<2010>
2011
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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|