Major Release "changes" Announcement

Printer-friendly

jNetPcap Version 1.2 software has gone through a number of revisions that were labeled 1.2.rc1 through 1.2.rc5. These revisions added new features and fixed numerous bugs. The jNetPcap Version 1.2 so far has been a major success. jNetPcap is being utilized for many different purposes. This includes embedding into a commercial products and utilization in major corporate infrastructure projects. Number of interested companies and users has been phenomenal and explosive.

Unfortunately, the current software release model is insufficient to address stability requirements of a major software package. Especially when jNetPcap is being utilized in production environments and even in commercial products requiring the utmost care taken when making decisions to include such sub-components as jNetPcap. The current release model is insufficient to address these concerns and has to be changed.

To address the above mentioned issues, jNetPcap software will adhere strictly to release guidelines, previously determined goals, objectives and milestones. The new release model will provide stability and pre-determination of when a release will be considered stable and usable for production environments.

The new development and release process will follow the following general guidelines.

Modularity

jNetPcap project will be made up of two modules:

  • jnetpcap module - main API and core protocols
  • protocols module - additional base of protocols

This is not a split into 2 modules, but the "protocols" module is in addition to the current software base. The jnetpcap module contains the same exact code as has been released so far and distribution packages which were named "jnetpcap-1.1-fc8-i386.rpm" for example, will be continue to be named identically. The jnetpcap module currently contains a builtin set of core protocols and it will continue to have exact same set of protocols.

The protocols module, will be a separate module, with its own distinct build scripts and release cycles. The purpose of this module is to release new protocols, in addition to the core protocols already present in the main jnetpcap module. All new protocols will be released under the "protocols" module which will be provided as additional file package that will need to be downloaded and installed. The "protocols" module will provide 1 or more jar files containing additional protocols that can be included with jnetpcap module. The protocols will integrate seamlessly with jnetpcap.

The protocols module will be released more frequently then the main jnetpcap module. It will however, go through the same release procedures as the main jnetpcap module described in the section below. This will gurrantee quality and a path to becoming stable, production quality.

Development Process

All major development of new features and protocols, will occur on the main development trunk of a module. The trunk will, as it does today, contain the latest and greatest features that are under development. Developers will deliver snapshots of the development trunk as daily, weekly, quarterly and milestone releases. These snapshots will be downloadable from SourceForge file release system.

Release Process

At some point, a decision will be made to release the software to general public. At that point the following release model and procedures will be used:

  • pre-alpha phase - a release snapshot will be made of the development trunk with all the intended features already developed. This will be a pre-alpha unstable release. This may be the first real look the jNetPcap community may have at the proposed features to be released. At this time, the development team will review feedback and possibly go back to development trunk to incorporate changes, requests, omitions and address other issues as determined after the public pre-alpha release
  • alpha phase - After feedback has been gathered and possibly additional pre-alphas released, a decision will be made to move into alpha phase. In alpha phase, all new features and development will be frozen. Only bug fixes and minor changes will be permitted.
  • beta phase - after 1 or more iterations of the alpha release, when sufficient defects have been cleaned up, the module will move into beta phase. In beta phase, the software has to already be in fairely stable state, but still defects and possible instability are still to be expected.
  • release candidate phase - eventually when beta has been thoroughly tested by developers and more importantly by the community, the software will be released as a "release candidate". A release candidate, contains the exact software state and condition as is expected in the final stable release.
  • stable phase - If no further bugs, issues with packaging, installation problems, platform interoperability and documentation issues exist in latest release candidate, the software will be released as the final "stable".
  • maintenance phase - even after the final stable release has been made, it is still possible to discover defects that will need to be addressed. At that time a maintenance release cycle will be started that will fix the defect or defects. The maintenance release will once again start at the "release candidate" phase. This will allow the community to verify that the defects have indeed been properly fixed and no other defects or issues with release itself have been introduced. After the maintenance "release candidate" phase has been determined to be complete, the final "stable" maintenance release will be made. If additional defects are further discovered after the initial maintenance release, the defects will be addressed in additional maintenance releases.

Distribution Packages on SourceForge FRS

To better incorporate new modules and development builds, the file release system (FRS) on SourceForget will incorporate new file release structure.

  • 2 additonal FRS packages have been added to a total of 3: "jNetPcap", "Extra Protocols" and "Dev Snapshots" packages are now available directly from the distribution server, although protocols and dev packages are currently empty. They will however be populated with newly released builds and packages.
  • Module packages "jNetPcap" and "Extra Protocols" will have 2 separate FRS releases for every release being made.
    • The first is the "Version X.Y - Preview" release. This FRS release will contain all the non-production file packages such as: pre-alpha, alpha, beta and release candidates.
    • The second is the "Version X.Y - Stable" release. This FRS release will contain all the final and stable release files. These packages will be considered production quality. This package may however contain additional maintenance updates, that have themselves gone through the "preview" stages. They will contain an extra version number, to indicate the maintenance release number (i.e. 1.2.1).
  • Dev Snapshot package - will contain various development trunk snapshots, using different naming convention for the build and milestones. They will also be grouped under a FRS release such as "q1-2009" indicating this is a grouping of dev builds in Q1 of 2009. The groupings are simply there to reduce the number of file packages found under a single level, to make it easier to find any particular one.

Existing jNetPcap Version 1.2 changes

In order to conform to the above development and release guidelines, the existing release version 1.2 will have to be modified. The existing version 1.2 release naming nomenclature is very misleading. All of the 1.2 releases have been mislabeled as "release candidates". This stems from the fact that initial 1.2 release had very minor enhancements that were almost ready for final release. After initial rc1 release had been made, significant new features were added and continued to be added and released as addition release candidates.

Version 1.2.rc5 contains 2 major feature sets that have been incorporated. First is the "packet decoder" and the second is the "protocol analyzer". These are both very major enhancements to jNetPcap and each of them is very complex. Complexity usually means that there will be issues and defects. The current mix of these 2 major features guarantees that release version 1.2 will be unstable for a long time to come. Therefore I have decided to split release version 1.2 a long the lines of "packet decoder" and "protocol analyzer".

The "packet decoder" feature has been present in jNetPcap from version 1.2.rc1 through 1.2.rc4. The "protocol analyzer" feature had only been introduced with the latest release 1.2.rc5. In reality the rc1 through rc4 could be considered incremental alpha stages of release 1.2 and this is how I would like to split the existing releases.

We will start the release process for version 1.2 from the beginning, but this time properly. I will make a new release version 1.2.alpha1. This release will be based on current release 1.2.rc4. It will also incorporate all of the rc4 API and bug fixes that were fixed up in the development trunk. The new release will correctly reflect the state of the software which is "alpha" stage.

The "protocol analyzer" feature will remain strictly in the development trunk and will eventually be released in the next new feature release cycle which looks to be version 1.3. The "protocol analyzer" feature will however be released very shortly as a development trunk snapshot. It will be released as a milestone or major feature development build under "Dev Snapshots" FRS package. For those of you waiting for 1.2.rc6 which would have incorporated various "protocol analyzer" fixes, will be able to use this new milestone snapshot. For others who wish for more stability can stick with the release alphas, betas and eventually final stable packages.

This split will address 2 key issues. Stability of the releases and flexibility of continuing development of jNetPcap features without affecting incubating releases. Since the new release, version 1.2.alpha1, will contain only the single, already tested "protocol decoder" feature, we can concentrate exclusively on this feature to bring the 1.2 release to stable status much much quicker then with the current combined model.

I realize this is a bit drastic change to the development process and the release cycle, and it is not ideal, but if we continue on the current track, I can not honestly tell anyone when we could eventually get to a final release and call it "stable". Further more, with the current development model of all the changes and release updates occurring on the singe development trunk, I'm being forced to seize any further development in order to eventually achieve a stable release. Therefore it is now time to fix this once and for all.

All future releases will follow this development and release model from the beginning. Bringing to new releases and development stability, predictability and flexibility. jNetPcap is growing up.