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
<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 Ralph Lange
- Next:
RE: Merges: 3.14.12 vs 3.15 Jeff Hill
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|