Jeanfrancois Arcand wrote:
> 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).
You can just login to nabble and register for this. Let me know, I can
just do that...
- Binod.
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>