Menu
▾
▴
Release
GHDL Release Process
This page documents the steps to be followed when preparing a GHDL Release.
At this stage it is a suggestion rather than an instruction, to get the ball rolling.
Suggestions, comments and criticisms are welcome on ghdl-discuss@gna.org
1) Name next release
This is easy. Having released ghdl-0.31, the next release will be ghdl-0.32.
Although it is too soon to create a branch, release tag names and a source distribution file, their names can be derived from the release name now to prevent surprises and inconsistencies later.
For example:
| Entity | Name |
|---|---|
| branch name | release-0.32 |
| first release candidate (tag) name | ghdl-0.32rc1 |
| second release candidate (tag) name | ghdl-0.32rc2 |
| release (tag) name | ghdl-0.32 |
| source release package | ghdl-0.32.tar.gz |
NOTE that SourceForge behaves very badly if e.g. a tag and a branch have identical names!
2) Roadmap next release
Decide which enhancements we aim to provide for the next release.
This need not be too fine grained (fix bug 20355) and may change as difficulties arise or developers volunteer. Broad goals such as "Support enough VHDL-2008 to run the VHDL-2008 version of the OSVVM demonstration" will help focus development in a specific direction.
However the goals should not be too ambitious like "Full VHDL-2008 compliance"!
3) Fulfil roadmap goals
At the end of this stage the development branch "default" broadly satisfies the roadmap goals. For example, in hindsight the 0.31 roadmap might have been the following:
1. Run the OSVVM demo in its VHDL-2002 version
2. Build ghdl against gcc4.8
3. Add 'image and 'value attributes for the full range of types, including physical types
4. Clear the bulk of outstanding bugs and support issues
4) Branch the release, generate RC1
Create a branch, and tag its first (or an early) commit as the first release candidate.
Development can continue on the "default" branch while this tagged version remains a (relatively) stable candidate for builds and tests on different platforms.
5) Test the release candidate
At this stage the basic functionality is already complete and tested on at least one platform. Here the aim is to extend that status to other platforms, and to achieve simple consistent builds that work (pass tests) on each platform.
Issues found here should normally be fixed in the default branch and backported to this branch. Fixes for minor outstanding bugs may also be backported, unless there is reason to believe they may affect the stability of the branch.
When all active maintainers have reported successful builds for their platform, this stage is complete. One way to handle this is an "ack" thread on ghdl-discuss.
6) Tidy up the release candidate
Checklist of places where release-dependent information is lurking and needs to be synchronised:
| File | To Fix |
|---|---|
| version.ads | Version number, copyright dates, release date |
| ... |
When these are all ticked off, stage 6 is complete.
Stages 5) and 6) can proceed in parallel. When both are complete we can tag the head of this branch as RC2.
7) Test RC2
This ought to be a formality, as most branch changes are to correct specific issues with RC1. When all active maintainers have reported successful builds for their platform, this stage is complete. Again, we can use an "ack" thread on ghdl-discuss.
8) Release
Tag the branch head with the release name.
Build a release package by "hg clone" to a new folder, "hg update" to the release tag, and building an archive (omitting the testsuite and hidden files such as .hg, .hgignore).
TODO : script this.
9) Binary builds
Binary builds should be clean builds from the release package to avoid discrepancies accidentally creeping in from development branches.
