Difference between revisions of "User:AndrewJohnson/Developing Future Releases"
(Added src/dbHost) |
(Suggested feature branches.) |
||
Line 1: | Line 1: | ||
This document proposes a method for managing development work intended for future releases of EPICS Base. | This document proposes a method for managing development work intended for future releases of EPICS Base. | ||
== Background == | |||
Developing new features for EPICS Base has always been limited by the complexities of managing significant code changes in the CVS repository. Work on bug fixes and minor new features was developed on the current release branch, while more extensive developments that were intended for the next major release took place on the main trunk. This has made it essential to coordinate development projects so that everything committed on the relevant branch is finished and working in time for the release. For long-term development work, this results in an inability to release a version containing some new features because others are still not finished. | Developing new features for EPICS Base has always been limited by the complexities of managing significant code changes in the CVS repository. Work on bug fixes and minor new features was developed on the current release branch, while more extensive developments that were intended for the next major release took place on the main trunk. This has made it essential to coordinate development projects so that everything committed on the relevant branch is finished and working in time for the release. For long-term development work, this results in an inability to release a version containing some new features because others are still not finished. | ||
Line 10: | Line 10: | ||
== Proposal == | |||
The current R3.14 branch should form the basis for the R3.15 release branch. All features to be included in R3.15 should be published as separate feature branches and proposed for merger into the new release branch. By | The current R3.14 branch should form the basis for the R3.15 release branch. All features to be included in R3.15 should be published as separate feature branches and proposed for merger into the new release branch. There might be no need to even create the 3.15 branch or series until a few months before the release date, thus we would set the 3.14 branch as the current focus of development. | ||
By doing this, changes that are made on the R3.14 branch after the R3.15 branch has been created can easily be merged into R3.15 as well with a simple 'bzr merge' from the R3.14 branch. This means that even after a new release comes out, bug fixes should first be committed on the earliest branch series that is still being supported (currently 3.14), and then these changes should be merged forward (adjusting as necessary) into the later branch series. | |||
=== Implications for the CVS Trunk === | |||
Adopting this proposal requires that all desired features that have already been added to the CVS trunk be extracted into new feature branches and published separately. Where there are dependencies between features the more dependent ones will need to be derived from the earlier feature branches, but doing so is not complicated as long as the relationships are clear. | Adopting this proposal requires that all desired features that have already been added to the CVS trunk be extracted into new feature branches and published separately. Where there are dependencies between features the more dependent ones will need to be derived from the earlier feature branches, but doing so is not complicated as long as the relationships are clear. | ||
A look at the differences between the two branches reveals the following | ==== Analysis ==== | ||
A look at the differences between the two branches reveals the following changes that were made on the cvs-trunk but not on the 3.14 branch, calculated by doing a diff and examining the things added. Note that this list does not mention features that have been added to the 3.14 branch but not to the cvs-trunk. Those feature should be kept, so the people responsible for creating the feature branches must be look carefully at the changes they're proposing, don't just commit whole files copied from the CVS trunk without reviewing them first. | |||
configure: | configure: | ||
Line 31: | Line 38: | ||
src/makeBaseExt: | src/makeBaseExt: | ||
* '' | * ''This directory may be unnecessary if we keep the Up stuff'' - ANJ | ||
src/libCom: | src/libCom: | ||
Line 108: | Line 115: | ||
src/rsrv: | src/rsrv: | ||
* Removed 3.13 compatibility from Makefile | * Removed 3.13 compatibility from Makefile | ||
* Removed SigAlarm calls from caserverio.c and caservertask.c | |||
* Added support for name searches over TCP in camessage.c | * Added support for name searches over TCP in camessage.c | ||
* Added rsrv_version_reply() call in caservertask.c | * Added rsrv_version_reply() call in caservertask.c | ||
* online_notify.c - some changes using osiIntfAddrNode may | * Increment CA_MINOR_PROTOCOL_REVISION in server.h | ||
* online_notify.c - some changes using osiIntfAddrNode may have been added in 3.14 and not copied to the trunk | |||
** There is also new code in this file though. | ** There is also new code in this file though. | ||
src/rec: | src/rec: | ||
Line 139: | Line 146: | ||
src/cap5: | src/cap5: | ||
No changes. | No changes. | ||
==== Extracting Features ==== | |||
The following feature branches are suggested: | |||
* Remove deprecations, 3.13 compatibility, sigAlarm, libCom/tsDefs, vxWorks dir | |||
* dbHost (Perl DBD file tools) | |||
* libCom/yajl (JSON support) | |||
* libCom/BaseString | |||
* CA over TCP (ssh-tunneling support) | |||
* TOP to Up conversion (not sure I like this, it's very invasive) | |||
* Other libCom branches as decided by Jeff | |||
* Other ca/cas/gdd/db branches as decided by Jeff | |||
Anything I've missed? |
Revision as of 21:42, 21 January 2010
This document proposes a method for managing development work intended for future releases of EPICS Base.
Background
Developing new features for EPICS Base has always been limited by the complexities of managing significant code changes in the CVS repository. Work on bug fixes and minor new features was developed on the current release branch, while more extensive developments that were intended for the next major release took place on the main trunk. This has made it essential to coordinate development projects so that everything committed on the relevant branch is finished and working in time for the release. For long-term development work, this results in an inability to release a version containing some new features because others are still not finished.
For minor changes that have been made on the current release branch, this has also required additional effort from the developers to ensure that their changes also get committed to the main trunk. Unfortunately the commit log messages for these secondary commits on the trunk have mostly become content-free, which makes them useless for future examination. The commit log messages on the branch however do contain useful information.
One of the advantages of using a Distributed Version Control System (DVCS) like Bazaar is the ability to use separate development branches. Each new feature is developed on its own private branch and the result only gets merged into the official repository once development is finished and the resulting code has been tested. The ability to review changes, ask questions and make comments on them before they get applied to the official repository should help improve the quality of future releases.
Proposal
The current R3.14 branch should form the basis for the R3.15 release branch. All features to be included in R3.15 should be published as separate feature branches and proposed for merger into the new release branch. There might be no need to even create the 3.15 branch or series until a few months before the release date, thus we would set the 3.14 branch as the current focus of development.
By doing this, changes that are made on the R3.14 branch after the R3.15 branch has been created can easily be merged into R3.15 as well with a simple 'bzr merge' from the R3.14 branch. This means that even after a new release comes out, bug fixes should first be committed on the earliest branch series that is still being supported (currently 3.14), and then these changes should be merged forward (adjusting as necessary) into the later branch series.
Implications for the CVS Trunk
Adopting this proposal requires that all desired features that have already been added to the CVS trunk be extracted into new feature branches and published separately. Where there are dependencies between features the more dependent ones will need to be derived from the earlier feature branches, but doing so is not complicated as long as the relationships are clear.
Analysis
A look at the differences between the two branches reveals the following changes that were made on the cvs-trunk but not on the 3.14 branch, calculated by doing a diff and examining the things added. Note that this list does not mention features that have been added to the 3.14 branch but not to the cvs-trunk. Those feature should be kept, so the people responsible for creating the feature branches must be look carefully at the changes they're proposing, don't just commit whole files copied from the CVS trunk without reviewing them first.
configure:
- Up files everywhere, and associated changes to Makefiles and RULES_ARCHS
- Added os/CONFIG* files for the linux-ppc-bgl architecture
src/tools:
- installEpics.pl Silence echo when -s in $ENV{MAKEFLAGS}
- makeMakefile.pl updates
src/makeBaseApp:
- Renamed top dir to template
- This change unnecessary, don't make - ANJ
src/makeBaseExt:
- This directory may be unnecessary if we keep the Up stuff - ANJ
src/libCom:
- New BaseString/
- test/BaseStringTest.cpp, test/SegBufferTest.cpp, test/TestSegString.h
- Many changes in cxxTemplates/
- New epicsThrowTrace, autoDestroyPtr
- epicsGuard.h and tsMinMax.h deleted
- New yajl/
- New EPICS_CA_NAME_SERVERS in env/envDefs.h
- Updates in fdmgr/
- New EPICS_UNUSED in misc/compilerDependencies.h
- New misc/EnclLnk.h
- New types in misc/epicsTypes.h
- Updates to misc/ipAddrToAsciiAsynchronous
- Deprecated EPICS_UPDATE_LEVEL removed from output of misc/makeEpicsVersion.pl
- Win32 visibility attribute used in misc/shareLib.h
- Major changes to osi/epicsMutex and osi/epicsThread
- WIN32/osdMutex drop support for W95/W98/WME
- WIN32/osdThread.c updates
- test/epicsMutexTest.cpp
- Makefile osdThread_CPPFLAGS setting
- No-throw guarantees and support for addNanoSec(-ve args) in misc/epicsTime
- Don't like those no-throw guarantees - ANJ
- New osdAtomic API in osi and osi/os/*
- test/osiAtomicTest.cpp
- Updates to osi/os/*/osdNetIntf.c (probably 3.14 missing from 3.15 though)
- Related changes in osi/osiSock.h
- Updates in osi/osiWireFormat.h and osi/os/default/osdWireFormat.h
- Removed all sigAlarm routines from osi/os/*/osdSignal.cpp
- Also enum change in osi/osiSock.h, test/blockingSockTest.cpp
- WIN32/epicsGetopt - mingwex library provides getopt(), don't build on mingw
- WIN32/osdProcess.c cleanup
- WIN32/osdTime.cpp updates
- WIN32/setThreadName.cpp updates
- test/cvtFastPerform.cpp using stmts.
- Removed 3.13 compatibility from Makefile
- Major updates in timer/
- Deleted tsDefs/
src/toolsComm:
- No changes.
src/ca:
- Many updates, not examined.
src/dbStatic:
- Removed 3.13 compatibility from Makefile
src/dbHost:
- New
src/registry:
- Removed 3.13 compatibility from Makefile
src/bpt:
- Added convertCommon.dbd and menuConvertCommon.dbd
src/db:
- Removed 3.13 compatibility from Makefile
- Major updates to the CA Server interface
- Renumber S_db_noMemory in dbAccessDefs.h
src/as:
- Removed 3.13 compatibility from Makefile
src/util:
- Build ca_test and iocLogServer on all host types
src/dbtools:
- Removed 3.13 compatibility from Makefile
src/catools:
- No changes.
src/rsrv:
- Removed 3.13 compatibility from Makefile
- Removed SigAlarm calls from caserverio.c and caservertask.c
- Added support for name searches over TCP in camessage.c
- Added rsrv_version_reply() call in caservertask.c
- Increment CA_MINOR_PROTOCOL_REVISION in server.h
- online_notify.c - some changes using osiIntfAddrNode may have been added in 3.14 and not copied to the trunk
- There is also new code in this file though.
src/rec:
- No changes.
src/misc:
- Removed 3.13 compatibility from Makefile
- id[] in epicsRelease.c - discard (ANJ)
src/dev:
- Removed 3.13 compatibility from Makefiles
src/vxWorks:
- Deleted.
src/RTEMS:
- No changes.
src/softIoc:
- No changes.
src/gdd, src/cas, src/excas:
- Many updates, not examined.
src/cap5: No changes.
Extracting Features
The following feature branches are suggested:
- Remove deprecations, 3.13 compatibility, sigAlarm, libCom/tsDefs, vxWorks dir
- dbHost (Perl DBD file tools)
- libCom/yajl (JSON support)
- libCom/BaseString
- CA over TCP (ssh-tunneling support)
- TOP to Up conversion (not sure I like this, it's very invasive)
- Other libCom branches as decided by Jeff
- Other ca/cas/gdd/db branches as decided by Jeff
Anything I've missed?