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
- References:
- Merges: 3.14.12 vs 3.15 Andrew Johnson
- Navigate by Date:
- Prev:
RE: Merges: 3.14.12 vs 3.15 nick.rees
- Next:
Re: [Merge] lp:~michael-abbott/epics-base/dynamic-array intolp:epics-base 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 nick.rees
- Next:
RE: Merges: 3.14.12 vs 3.15 Davidsaver, Michael
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|