User:AndrewJohnson/Developing Future Releases

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. 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.

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 some features that have been added to the 3.14 branch but not to the cvs-trunk:

configure:

• Up files and associated changes to Makefiles and RULES_ARCHS
• CONFIG files for the linux-ppc-bgl architecture

src/libCom:

• New BaseString/
• Many changes in cxxTemplates/
• 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
• 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/os/*
• Updates to osi/os/default/osdNetIntf.c (or missing changes?)
• Updates in osi/os/default/osdWireFormat.h