I vote for 1.6.0
WBR,
Alexey.
Jeanfrancois Arcand wrote:
>
>
> Jeanfrancois Arcand wrote:
>> Hi,
>>
>> several weeks have passed since we have released 1.5.2 and I would
>> like to cut a new release. We have made API changes since 1.5.2
>> (making sure we are always backward compatible. See [1]) and I would
>> like to propose the following VOTE:
>>
>> [ ] Yes, release 1.5.3
>> [ ] Yes, release 1.6.0
>> [ ] No release, I've an issue with my application
>>
>> During today's open phone call, we have agreed, based on [2]
>> proposal, that releasing 1.6.0 would be the best version...still we
>> would like to know what other thinks.
>>
>> The vote will close Friday 12h00pm PST.
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>> [1]
>> https://grizzly.dev.java.net/source/browse/grizzly/trunk/CHANGELOG.txt?rev=450&view=markup
>>
>> [2] (Nabble didn't have it)
>>
>>> 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
>