An attempt at a summary on this topic.
The majority view on the thread was that a major version should not be
mandated to mean a package rename. Instead, the view most widely
expressed was that this should be a component decision.
A second angle to emerge is that a 'large non-compatible change', as per
[collections] for generics, may in fact be a change larger than our
current major version number expresses. Going forward, this may argue
for a different component name, if package renaming does not have
widespread support.
I'm not planning on bringing this to a vote, as it would be defeated as is.
Stephen
Niall Pemberton wrote:
On 10/30/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
From: Sandy McArthur <[EMAIL PROTECTED]>
> If we want to come up with the notion of a "super" version, something
> that is more broad than a "major" version and includes non-backwards
> compatible changes I'm fine with that.
>
> But mandating that any major release be completely non-backwards
> compatible is silly.
So what does a major version mean? Surely a major version means "we
have changed the code so it is no longer compatible, you cannot
upgrade simlpy and easily"
> Occasional drastic pruning of code is needed to keep it healthy and
> manageable. But we should not be eager to run out and break
> compatibility without deliberate and compelling reasons.
I agree that we should not run out and break compatibility without
deliberate and compelling reasons. In fact, I'd suggest that one of
the beneficial side-effects of adopting this as a policy would be that
we would all be more reticent about making those incompatible changes,
leading to more minor and compatible releases - which I would argue is
a Good Thing.
I'll admit its less fun though. Is that what the negative viewpoint
here is? Or is it just that the negatives have never faced jar hell?
At the moment, I haven't heard any debate of the validity of the
problem, or alternatives to the solution/
The alternative solution is to use the deprecate / remove cycle in the
event of backwards incompatibility. For some components I agree this
could result in "jar hell" and is not appropriate - but for others its
a valid approach. Some components are more widely depended on than
others. For example Validator 1.2.0 removed a whole load of deprecated
items and I've not seen one complaint of jar hell - probably for two
reasons - 1) people don't usually depend directly on Commons Validator
- they use XML to configure it and as long as they have the right
config, it works - 2) its mainly only a Struts dependency and not a
widely used dependency.
I think theres a few factors which influence the decision:
1) How deep (widely depended on) a component is.
2) How long a features been deprecated.
3) How significant the backwards incompatiblity is
By mandating the "package rename" route we prevent individual
components taking into account the above factors and making their own
decisions. Ruling out the java "deprecation" feature is a bad decision
IMO as well as guranteeing user pain - whether necessary or not. I'm
not saying I'm against "package renaming" - its a good decision in the
right circumstances - I'm just against having it as a requried policy.
If we go this route I forsee people voting -1 on releases "just
because its policy" - whatever valid arguments a particular component
developers make for choosing an alternative route.
Niall
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
