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
>