<module>-<version>.<build#>[-<date>][-<special name>]
Where:
- module = either jnetpcap or jnetpcap-protocols
- version - best guess and estimate for the target release build's features are destined. This is an estimate only, and features present in this build could be delayed or completely removed.
- build# = unique incremental build number of this particular build (a 'b' followed by 4 digits padded with zeros). Every time a release is made or packaged, a unique build number is assigned. Usually this is a number that is incremented by one with every single build of the module.
- date = (YYYY-MM-DD) YYYY a 4 digit year, MM a 2 digit month, DD a 2 digit day of the month. Typically the date of the build.
- special name = can be name of a source tree branch, a milestone, or any other special designation, not used in installation, but helpful in identifying the release features for example. Its is also encouraged to specify within the name the features that were added and defects that were fixed in this release in the form of a prefix letter followed by numerical id.
- f001 - a feature with 3 digit id. The last 3 digits of the feature ID are used for brevity, if there is a conflict with another feature, use as many digits as neccessary to resolve the conflict. IDs assigned by ticketing system are usually 6, 7, or 8 digits long.
- d001 - a defect with 3 digit id. The last 3 digits of the defect ID are used for brevity, if there is a conflict with another defect, use as many digits as neccessary to resolve the conflict. IDs assigned by ticketing system are usually 6, 7, or 8 digits long.
- t20080410 - time based id with 8 digit date encoded. The date is encoded as
YYYYMMDD with 4 digit year, 2 digit month (zero padded) and 2 digit day of the month (zero padded).
Ongoing development on jNetPcap modules is done continuesly on each module's source trunk. Whenever the trunk development contains enough stable features to warrant a development snapshot release, the following convention is used to name the snapshot release and release it.
A development snapshot build, is a fully functional release. But the release does not guarantee any type of stability (outside of general prudence), does not guarrantee that API will not change in the future or that entire features will be removed from the development branch. Another words, development snapshot builds, are a capture of work in progress that may change in the future.
Here is an example of a development build snapshot:
jnetpcap-1.3.b0001-f123-d321 <= build with feature #123 and fixed defect #321
jnetpcap-1.3.b0002-milestone1 <= reached a milestone in the overall plan
pheonix-branch-1.3.b0013 <= snapshot of a source branch codenamed "pheonix"
jnetpcap-1.3.b0013-t20080408 <= time based snapshot on 2008.04.08
jnetpcap-1.3.b0014 <= a normal snapshot, probably a daily build
There are no alpha, beta, release-candidate or maintenance number designations. If there is something wrong with the build, a new build will have to created with higher build number and possibly a later date of the build. What is contained within each snapshot build has to be communicated to the community via website and updated change log and release notes.
