SDCC 2.4.0 Release - roybaer/sdcc-wiki GitHub Wiki

Table of Contents

Status

  • 17 Jan 04 - Page created
  • 20 Jan 04 - Compiles and installs cleanly on Mac OS X. Z80, mcs51, and ds390 regression tests all pass.
  • 25 Jan 04 - host regression tests all pass. Compiles cleanly on Redhat 9.0 but does not install cleanly. I could fix it if sf's CVS server was working...
  • 10 Feb 04 - Compiles and installs cleanly on Gentoo 1.4. Regressions pass on Z80, mcs51, and ds390.

Todo

  • Decide on #pragma support

Target platforms

SDCC will be built for the following platforms, in order of importance:

  1. Microsoft Windows 98 and above (win32)
  2. glibc based Linux (linux)
  3. Mac OS X 10.2 (darwin)
gcc and command line tools will be used to build all versions. MichaelHope doesn't have Visual C or Borland C and can't test those.

Processor targets

Some targets are not ready or are no longer maintained. Any mature targets must be included and must pass the regression tests. Any others may be disabled in the binary to meet the acceptance criteria .

  • Mature, on-going maintanance: mcs51, ds390, z80
  • Preliminary, in development: pic14, pic16, hc08
  • No longer maintained: avr, gbz80
  • Unknown status: TININative, xa51, ds400

Deliverables

The final deliverables will be:

  • A source archive that can rebuild all binaries
  • An executable, NSIS based installer for Windows
  • A tarball that installs in /usr/local for Debian Linux 3.0
  • A tarball that installs in /Developer/SDCC for Mac OS X 10.2.8

Acceptance criteria

The release needs to at minimum:

  • Have an updated README
  • Compile without warnings or errors on all target platforms
  • Pass all regression tests on Linux and Mac OS X

Schedule

This schedule has no dates attached due to the volunteer nature of the project, however MichaelHope will try to keep things moving.

The schedule and approximate timings are:

  1. Announce intention to do a release
  2. Take feedback and wishlist items (1 week)
  3. Decide on what structural changes have to be made
  4. Make any structural changes (1 week)
  5. Announce a bug hunt (1 week)
    1. Developers should refrain from adding new features
    2. The release manager will being cleaning up the build
    3. Developers should take the oppertunity to close any easy bugs
  6. Announce a code freeze (1 day)
    1. The release manager will make a first past build
    2. If it is clean or simple to clean, then a release branch will be made. Otherwise run another bug hunt.
  7. All deliverables will be built off the release branch (1 day)
  8. Deliverables will be released to the staging area so that people can test the installers.
  9. Quick test of the installers (2 days)
  10. Deliverables will be blessed and released.

Tasks

Random set of tasks that someone might want to do:

  • Update the web page before and after the release
  • Update the documentation
⚠️ **GitHub.com Fallback** ⚠️