These are the steps needed to build an LSB release. The software steps (from "Build Packages" on) are per-architecture - with seven architectures (as of LSB 2.0) this is a very time-consuming process.
Each release is tracked by a single rollup bug which breaks out into individual rollup bugs at least for the major categories (spec, runtime tests, application tests, application battery, sample implementation, build environment) - add more categories as needed. For easy searching, these special bugs should be tagged with a keyword rollup. All blocker bugs need to be addressed for a final release.
A template completion checklist is provided at the end of this page, and these items at a minimum must be followed for a release (add more as appropriate).
Most of the same steps apply to test building an individual module intended as an add-on. The database changes should be applied to a local machine with a populated database, and the sources generated from there. There are two objectives to such a build: to make sure that the additions to support the module propagate to the spec and all appropriate tools and are correct; and that the existing content that is not part of this module did not change in any way. It's not necessary to execute the runtime test suites except for the ones which test the module itself. Additional appbat applications which exercise the libraries of the module should be folded in for the test build. The additions to the lsbsi should be built, installed, and subjected to appropriate testing.
specdband the dump checked in to cvs. The database changes need to be complete before the rest of the release steps can be completed.
make distcleanfollowed by
tests/misc, and in the three
lsbspecdirectories, do a
make gensrc. If everything seems okay, check in the generated files.
TODO: add some "make check" type tests to the generation steps to try to validate early.
build_env/headersdirectory checked out. The Specification must be built after the headers and db-generated pages are created.
See XXX for instructions.
Once the Specification is considered "Code Complete" it enters a phase where Release Candidates are produced in addition to daily builds. Release candidates are numbered X.yRCn. Once all bugs have been verified, and the formal review period has ended, a final Release candidate is built, and this version of the spec is then put to a vote in the Specification subgroup. Upon approval of the subgroup, the Specification shall be published as a final release, numbered X.yFinal. This version of the spec is then put to a vote in the LSB Steering Committee. Once approved, it is submitted to the FSG Board of Directors for signoff there.
Upon approval of the FSG BOD, the spec is rebuilt with the number X.y, and copied into the Reference Specification area. At this point, the specification is considered published.
As a product is actually released, the cvs tree for that product should be tagged. The naming convention is LSB_X_Y_Z, with the _Z omitted if not needed, as in LSB_3_0 and LSB_2_0_1. For the spec, test releases (betas, release candidates) should also be tagged. Once work is ready to begin on a new major version, a tag should be created to allow a branch - but don't create the branch until it is needed, since as soon as there's a branch developers need to consider whether their changes must be applied to multiple branches. The naming convention here is LSB_X_branch.
packagingdirectory, build and install lsb-build-base, lsb-build-cc, lsb-build-c++, lsb-libchk and lsb-appchk. To be strictly correct, lsb-build-c++ should be built last, and twice, as it uses itself to build. If there has not been a change to the base packages (gcc-core and gcc-g++) the rebuild may not be needed, although major changes to lsb-build-base do have the possibility of affecting it.
tests/misc/devchk/ts/devchkwith cc and lsbcc, understand any failures and document. If there are database changes as a result of this process, the cycle will restart.
tests/misc/dynchkto check for interface prototype inconsistancies
XXX information incomplete
lsb-pythonfrom application battery, which should be built and installed first.
tests/qm/package. TODO: move build area to
tests/qmtest_package. TODO: move build area to
lsb-build-libbat, the LSB's informal build of a few development libraries (as .a's)
./configure. Resolve fatal errors by installing missing packages - usually -dev (or -devel) versions of packages that are not installed by default.
make phase3 phase4
pub/lsb/test_suites/beta/binary/runtime- some binary packages have an architecture subdirectory, some do not)