What is a minor x.x.x release for?
Consider the recent modeler vote for 2.0.1. This will probably go
through very quickly, and that is because the change involved is tiny
and non controversial. That is what these releases are for IMHO - fixing
up release process mistakes and major bugs.
As a general rule, commons has always preferred x.x releases to fix
bugs. Especially bugs which involve the creation of a new class, and the
deprecation of an entire existing class.
Personally, I expect to be able to drop in a x.x.x without thought. In
this case, a LOT of thought is being asked to remove the deprecation.
(Although deprecation doesn't require immediate action, many shops
require that)
To change an application which relies on a static utility class (easy to
use, available directly from anywhere), to one using a bean which has to
be manually managed (create, delete, pass around to point of use) is a
big deal. That doesn't come anywhere close to my definition of an x.x.x
release.
This isn't about deprecation per se, but the scale of change. I would
accept a deprecation of a single method in a non-major part of the
library in a x.x.x, but not a whole class where the way to solve the
deprecation is so hard.
My opinion is that this should be a 1.4.
However, if you wish to release more quickly, I offered the option of
removing the @deprecated from the static utility class for 1.3.2.
Should I do the work? Well, I generally take the view that the RM is in
control of the sourcebase during the release period. We also haven't
taken a decision on which of the two approaches to take. Finally, as I
have previously indicated, my involvement in commons is currently fairly
limited due to my JSR310 commitments.
However, should you request that I make a change here (the group should
decide which change), then I will try and fit it in.
Stephen
Jochen Wiedmann wrote:
On 6/20/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
It is up to the RM, but with a -1 from a major contributor to the code
base, I would personally not push out the release. FWIW, as mentioned
on other threads, I agree with Stephen on the version number issue.
The problem is simply that votes for releases on commons drive me sick.
It is not the exception, but the standard, that people demand changes
(which they of course assume that the RM will do) and use a -1 to
enforce their opinion.
I have a different opinion in this matter. I see absolutely no problem
with a compiler warning as long as I may drop in the binary to a
running system: *That* is what I call binary compatible and what
assume to be the contract for binary releases.
My point of view is that he or she who demands such work (going
through the docs and find all occurrencies of 1.3.2 and such is a
nontrivial work and will easily take two hours or so) should be ready
to do it for himself *or* leave it up to me to decide.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
