OpenFlow Releases

From OpenFlow Wiki

Jump to: navigation, search

OpenFlow Releases

Version    Status Date            Information    Release Notes Bugs Git Tarball Included
1.1 CURRENT Feb 28, 2011 Wiki Page Release Notes Trac Git openflow-spec-v1.1.0.pdf Spec Only
1.0 STABLE Dec 31, 2009 Wiki Page Release Notes Trac Git openflow-1.0.0.tar.gz Spec+Release
0.9.0-rev1 - Sep 4, 2009 Wiki Page Release Notes Trac Git openflow-0.9.0-rev1.tar.gz Spec+Release
0.9.0 - Jul 20, 2009 Wiki Page Release Notes Trac Git openflow-0.9.0.tar.gz Spec+Release
0.8.9 rev-2 - Feb 04, 2009 Wiki Page Release Notes Trac Git openflow-0.8.9~2.tar.gz Spec+Release
0.8.9 - Dec 2, 2008 Wiki Page Release Notes Trac Git openflow-0.8.9.tar.gz Spec+Release
0.8.2 - Oct 17, 2008 Wiki Page Release Notes Trac Git openflow-v0.8.2.tar.gz Spec+Release
0.8.1 - May 20, 2008 Blog Post Change Log Trac Git openflow-v0.8.1.tar.gz Spec+Release
0.8.0 - May 5, 2008 n/a Change Log   Trac Git openflow-v0.8.0.tar.gz Spec+Release

For older releases see the Version Archive

Release Process

The OpenFlow Spec and Reference Implementations are available from two different sources:

The life cycle for a new OpenFlow release is:

  • Planning. New features and spec changes are recorded on a wiki page, then discussed on the OpenFlow-discuss and OpenFlow-spec mailing lists. Change requests come from both vendors and researchers; this is meant to be an open process.
  • Implementation. Once a feature has been agreed upon, the implementation starts with a single commit to a new feature branch. This commit includes the set of changes to the OpenFlow spec, as well as any changes to openflow.h; it defines a contract (which may be changed as the implementation progresses) of what must be changed to OpenFlow to implement the new feature. Each new feature goes into its own branch on the public OpenFlow git repository, prepended by the developer's handle. The feature branch should include regression tests, changes to the Wireshark dissector, and updates to man pages.
  • Review. The burden is on the feature developer to find at least one developer to do a public code review before any code may get pushed to the testing branch. This may require multiple passes and should result in code improvements.
  • Testing. As a first check, the release candidate is run against our regression suite, which tests individual OpenFlow message types (black_box tests), as well as checks that the sample controller plus the OpenFlow switch act as an Ethernet switch (learning_switch tests). The Wireshark Dissector is hand-verified by checking its output during a run of the black_box tests. In addition, we do feature testing with the release candidate by adding it to whatever apps we're currently running on top of OpenFlow and checking that nothing breaks.
  • Release. The release is tagged in Git, and posted on the Download page.
  • Maintenance. Bug fixes releases come after new-feature releases.
Retrieved from "http://www.openflow.org/wk/index.php/OpenFlow_Releases"