Hello.
I've commited all ConnectionCache integration code including changes we
spoke during the last meeting.
So it's not a stopper for next release any more :)
WBR,
Alexey.
Jeanfrancois Arcand wrote:
>
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>