Difference between revisions of "User:AndrewJohnson/Developing Future Releases"

From EPICSWIKI
(Finished summarizing libCom, tools, makeBaseApp)
(→‎Analysis: config)
 
(3 intermediate revisions by the same user not shown)
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 ===
== 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 ===
== 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 adopting this approach, 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 also means that bugs should first be fixed in the earliest branch series that is still being supported, and then these changes should be merged forward (adjusted as necessary) to later branch series.
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 features are present on the cvs-trunk but not on the 3.14 branch.  Note that this list does not mention features that have been added to the 3.14 branch but not to the cvs-trunk, the assumption is that those should stay:
==== 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:
* Up files everywhere, and associated changes to Makefiles and RULES_ARCHS
* Up files everywhere, and associated changes to Makefiles and RULES_ARCHS
* Added os/CONFIG* files for the linux-ppc-bgl architecture
* Added os/CONFIG* files for the linux-ppc-bgl architecture
config:
* Deleted (3.13 compatibility)


src/tools:
src/tools:
Line 29: Line 39:
* Renamed top dir to template
* Renamed top dir to template
** ''This change unnecessary, don't make'' - ANJ
** ''This change unnecessary, don't make'' - ANJ
src/makeBaseExt:
* ''This directory may be unnecessary if we keep the Up stuff'' - ANJ


src/libCom:
src/libCom:
Line 67: Line 80:
* Major updates in timer/
* Major updates in timer/
* Deleted tsDefs/
* 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?

Latest revision as of 23: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

config:

  • Deleted (3.13 compatibility)

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?