On Thu, Nov 25, 2010 at 4:29 AM, Matt Benson gudnabr...@gmail.com wrote:
On Nov 24, 2010, at 2:54 PM, Niall Pemberton wrote:
On Wed, Nov 24, 2010 at 7:43 PM, James Carman
ja...@carmanconsulting.com wrote:
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I
On 25 November 2010 12:01, Niall Pemberton niall.pember...@gmail.com wrote:
slightly OT
IMO changing the package name is always a bad idea and I think we have
been too quick to do it, rather than trying to retain compatibility.
Its effectively starting a new component and perhaps merited on
Hi,
Here is my rule: if the binary compatibility is broken in a
significant way, then the package/artifactId must change, however all
binary incompatibility should be avoided wherever possbile.
How can one usesuch an ill-defined notion as 'significant' in the defini-
tion of a **rule**?
On 25 November 2010 12:47, Dimitri Pourbaix pourb...@astro.ulb.ac.be wrote:
Hi,
Here is my rule: if the binary compatibility is broken in a
significant way, then the package/artifactId must change, however all
binary incompatibility should be avoided wherever possbile.
How can one usesuch
We've had this package name/artifactId change discussion numerous
times and I think it's time we put this thing to a vote. What I
propose is that we say that this is a rule and in order to break
that rule, you have to provide strong evidence that the component's
situation is unique and not
On 24 November 2010 15:36, James Carman ja...@carmanconsulting.com wrote:
We've had this package name/artifactId change discussion numerous
times and I think it's time we put this thing to a vote. What I
propose is that we say that this is a rule and in order to break
that rule, you have to
While I hardly count as having a vote now, I do have an opinion ;-)
I think that the formulation below is too strong. I'd argue that
changing the package name is required when there is significant
incompatibility, but a major version change might not cause such
incompatibility.
For example, if a
On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
scolebou...@joda.org wrote:
For example, if a whole set of new features is added, it can be worth
using a new version number for marketing reasons (advertising the
major new features). This can result in a major version that is still
+1
Gary
On Nov 24, 2010, at 7:36, James Carman ja...@carmanconsulting.com wrote:
We've had this package name/artifactId change discussion numerous
times and I think it's time we put this thing to a vote. What I
propose is that we say that this is a rule and in order to break
that rule, you
On Wed, Nov 24, 2010 at 11:07 AM, sebb seb...@gmail.com wrote:
A major version change requires that you change the package name (the
part that comes after org.apache.commons) and the Maven artifactId to
the component's name with the major version appended to the end.
[ ] +1 - accept this as a
On Wed, Nov 24, 2010 at 10:36 AM, James Carman
ja...@carmanconsulting.com wrote:
[ ] +1 - accept this as a rule
[ ] -1 - do not accept this as a rule
Here's my +1
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
scolebou...@joda.orgwrote:
While I hardly count as having a vote now, I do have an opinion ;-)
Cycles welcome :))
I think that the formulation below is too strong. I'd argue that
changing the package name is required when there is
On Nov 24, 2010, at 8:18 AM, James Carman wrote:
On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
scolebou...@joda.org wrote:
For example, if a whole set of new features is added, it can be worth
using a new version number for marketing reasons (advertising the
major new features).
On Nov 24, 2010, at 7:36 AM, James Carman wrote:
We've had this package name/artifactId change discussion numerous
times and I think it's time we put this thing to a vote. What I
propose is that we say that this is a rule and in order to break
that rule, you have to provide strong evidence
On Wed, Nov 24, 2010 at 3:36 PM, James Carman
ja...@carmanconsulting.com wrote:
We've had this package name/artifactId change discussion numerous
times and I think it's time we put this thing to a vote. What I
propose is that we say that this is a rule and in order to break
that rule, you
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I disagree. The rule should be that a new package and artifactId is
required when compatibility is broken, not when a version change occurs.
Exceptions should be based on that policy, not on a version change
On Wed, Nov 24, 2010 at 12:16 PM, Niall Pemberton
niall.pember...@gmail.com wrote:
Package name change decisions should be based purely on whether a
component decides whether breaking binary compatibility is acceptable
or not.
I also think conflating version/packagename/maven issues causes
Le 24/11/2010 20:43, James Carman a écrit :
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I disagree. The rule should be that a new package and artifactId is
required when compatibility is broken, not when a version change occurs.
Exceptions should be
Am 24.11.2010 21:17, schrieb Luc Maisonobe:
Le 24/11/2010 20:43, James Carman a écrit :
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I disagree. The rule should be that a new package and artifactId is required
when compatibility is broken, not when a
Luc Maisonobe wrote:
Le 24/11/2010 20:43, James Carman a écrit :
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I disagree. The rule should be that a new package and artifactId is
required when compatibility is broken, not when a version change occurs.
On Wed, Nov 24, 2010 at 7:43 PM, James Carman
ja...@carmanconsulting.com wrote:
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I disagree. The rule should be that a new package and artifactId is
required when compatibility is broken, not when a version change
They would need to change together to be of any use obviously.
On Nov 24, 2010 3:55 PM, Niall Pemberton niall.pember...@gmail.com
wrote:
On Wed, Nov 24, 2010 at 7:43 PM, James Carman
ja...@carmanconsulting.com wrote:
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com
On Nov 24, 2010, at 11:43 AM, James Carman wrote:
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I disagree. The rule should be that a new package and artifactId is
required when compatibility is broken, not when a version change occurs.
Exceptions
That's already part of the binary compatibility rule
On Nov 24, 2010 4:31 PM, Ralph Goers ralph.go...@dslextreme.com wrote:
On Nov 24, 2010, at 11:43 AM, James Carman wrote:
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I disagree. The rule should be that a
On Nov 24, 2010, at 2:54 PM, Niall Pemberton wrote:
On Wed, Nov 24, 2010 at 7:43 PM, James Carman
ja...@carmanconsulting.com wrote:
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I disagree. The rule should be that a new package and artifactId is
25 matches
Mail list logo
