Matt Hogstrom wrote:
*What constitutes a release?*
Speaking from my IBM WebSphere days (just as a point of reference for
discussion and not specifically a recommendation) we generally
differentiated products based on Versions and Releases. Versions were
significant new content and function which might be defined as a new
J2EE specification implementation, significant new function
(clustering improvements might fall in this category), etc.
Releases were less dramatic and more incremental in nature. They
could include performance improvements, new features that were not
disruptive to previous releases (such as improved CMP persistence
options, etc.) or perhaps even a JDK Version upgrade from 1.4 to 1.5
for instance. Releases could also include what we referred to as tech
previews. These were items that we wanted people to have a chance to
start using but it wasn't fully baked yet. However, we did not want
to wait a whole version release to put it in the hands of the users.
So for notational usefulness. We saw a version number break down like
v.r.m where V is the major version number, R was the release number
and M was a modification level.
Modification levels could include new features of a limited nature as
described above. One was simply aware of how it would impact the
users in terms of determining appropriateness.
Thoughts?
I prefer the more conventional nomenclature of major, minor, and patch.
The explain this I will grossly plagiarize what Noel Bergman posted on
the James list.
X.Y.z: patch release - bug fixes
X.y: minor release - bug fixes and compatible enhancements
x: major release - major enhancements, and incompatible changes
I am very much against placing anything but patches in the .z releases.
Let me explain why. When we make a minor release we basically branch
the X.y release for the purposes of releasing patches. Any changes to
this branch, e.g. patches, must also be immediately applied to the
trunk. If we make any enhancements to this branch, we must also
immediately apply the same enhancement to that branch. This adds
significant more risk that bug patching but more importantly when we
fall into the trap of putting minor enhancements into a patch release,
we remove the most serious impetus to getting the minor release done and
out the door.
Let us make an honest assessment of ourselves based on past out
behavior, we do not have the discipline that it takes to put only minor
enhancements into a patch release.
Regards,
Alan
