commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [PROPOSAL] Major versions require package name change
Date Wed, 01 Nov 2006 22:59:02 GMT
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 <scolebourne@btopenworld.com> wrote:
> 
>> From: Sandy McArthur <sandymac@apache.org>
>> > 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message