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.