Hi,
I would like to do an official release of Project Grizzly this week.
I've already started pushing the snapshot so people that build their
application can just download the src/bin without having to checkout the
workspace. I would like to start a vote on:
+ What will be the release version: 1.5.1 or 1.6. Please see Ken's
proposal below. I'm tempted to use 1.5.1 just because it is a follow up
to 1.5.0 with more functionality, and bumping the version just after
1.5.0 is a little strange.
+ Stability of the release
Please let me know what you think. Do someone knows how to register
Grizzly's mailing list to nabble.com (archive mailing list).
A+
-- Jeanfrancois
> -------- Original Message --------
> Subject: A Proposal for Release Numbering Conventions for Grizzly
> Date: Wed, 16 May 2007 12:52:31 -0700
> From: Ken Cavanaugh <Ken.Cavanaugh_at_Sun.COM>
> Reply-To: dev_at_grizzly.dev.java.net
> To: dev_at_grizzly.dev.java.net
> CC: Ken Cavanaugh <Ken.Cavanaugh_at_Sun.COM>
>
>
>
> 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.