Aaron Mulder wrote:
I'd feel a lot better about tight restrictions on 1.1.1 if we really
made 1.2 a "minor release" and put all the stuff on the plate for 1.2
into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs
more than hot fixes. On a related point, I'm not sure we want
multiple big version releases per year.
I agree with you here. The nice thing about the policy that I outlined
below is that we can safely time box patch releases.
As for what gets scheduled for what release, I think that it's not
realistic to start by stacking a release w/ issues and hope that people
will "show up" to get them done in the scheduled time frame; this only
works if we are making shoes ;). With that said, time boxing is what
would work best with our unique body of developers.
Working within the strict interpretation of releases that I outlined
below, people would schedule themselves in with concrete commitments.
Bugs would not get scheduled in until someone actually picked it up and
started working on it. At that time, the developer would mark what
releases his changes would fix.
Features would not get scheduled in until someone actually commits to
doing that feature. The larger the feature, the stricter the
requirements are for milestones.
Regards,
Alan
On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
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
