Re: New release this week?
Binod wrote:
> 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...
Thanks! Just did it.
-- Jeanfrancois
>
> - 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>