Hi Ken,
Ken Cavanaugh wrote:
> 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 for writing this. A big +1 from me :-)
-- Jeanfrancois
>
> Thanks,
>
> Ken.
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net For additional
> commands, e-mail: dev-help_at_grizzly.dev.java.net