One of the things we discussed at today's grizzly meeting was release
numbering.
The current Grizzly release is 1.5.0. We propose following a fairly
conventional
major.minor.patch release number scheme:
- The major number will be incremented whenever an incompatible
interface change is made, or when a very large scale change is made to
the Grizzly functionality. I expect that a major release would occur
yearly or less often. If an incompatible interface change is made, the
old branch will be maintained so long as there are Grizzly users that
require the old branch.
- The minor number will be incremented whenever new functionality
is added to Grizzly. This could take the form of new API classes, new
methods on existing API classes, or new functionality added to existing
methods. I expect that minor release will be fairly frequent for some
time to come, probably weekly to monthly.
- The patch number will be incremented whenever a bug fix or other
small change is released. patch releases will be made as often as
necessary, typically when a user of Grizzly requires a fix, or when a
committer has changed enough of the code to warrant a release.
It is not necessary to create a new release for each update to the
subversion repository, though a
single update may certainly result in a new release. Every release
should be announced to the Grizzly dev alias. This should also tie
into the Wiki that Jean-Francois is
exploring for tracking Grizzly development.
This proposal is related to Jean-Francois' proposal for sending
notifications to the dev alias about
upcoming changes. Such notifications should indicate which level of
release they require
(major/minor/patch), and may propose an appropriate release number when
possible.
Eventually Grizzly may need to consider how to handle incompatible
changes. The JDK has
always maintained a strict backward compatibility requirement, which
means that deprecated
methods have (so far) never been removed. This complicates the API and
has its own drawbacks,
while giving customers a very important feature: strict binary
compatibility from release to release.
This model is not appropriate for Grizzly, because grizzly is still
evolving rapidly. However,
Grizzly has also gather a significant developer base which we must
support. Therefore,
Grizzly should probably adopt the following policies for compatibility:
- Major releases MAY break strict backward compatibility. In this
case (as already mentioned above), the older major release will still
be maintained (and may gain patches and even minor releases if
required) so long as there are Grizzly users that require the older
releases. A new major release SHOULD provide guidance on what users of
an older release must do to migrate to the new release.
- Minor releases and patches MUST maintain strict backward
compatibility with previous versions of the same major release.
Please send comments, questions, and concerns about this proposal to
the Grizzly dev alias.
Thanks,
Ken.