[VOTE] Accept the package name/artifactId guideline as a "rule"...

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Accept the package name/artifactId guideline as a "rule"...

James Carman
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 affected by the issues that this rule
tries to address.  This is to avoid re-hashing this argument all the
time.  If a component wants to break the rule, then they should think
through the arguments (read the Wiki page first) and carefully
consider why they feel they are unique and unaffected by the issues.
So, here's the rule:

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 rule
[ ] -1 - do not accept this as a rule

Note that we already have a "rule" that says if you're going to break
binary compatibility, you have to change the major version number, so
this rule picks up where that one leaves off I guess.

p.s.  We might also want to propose a rule that says any new releases
of a commons component have to be done in the org.apache.commons
groupId, but that's another issue.

p.p.s. If anyone cares to restate this rule, please feel free to do
so.  I may not have addressed certain "gotchas", but the general idea
is presented.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

sebb-2-2
On 24 November 2010 15:36, James Carman <[hidden email]> 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 that the component's
> situation is unique and not affected by the issues that this rule
> tries to address.  This is to avoid re-hashing this argument all the
> time.  If a component wants to break the rule, then they should think
> through the arguments (read the Wiki page first) and carefully
> consider why they feel they are unique and unaffected by the issues.
> So, here's the rule:
>
> 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 rule
> [X] -1 - do not accept this as a rule

Components should be allowed to increment the major version even if
there is no binary incompatibility.

A package name change forces total binary incompatibilty.

> Note that we already have a "rule" that says if you're going to break
> binary compatibility, you have to change the major version number, so
> this rule picks up where that one leaves off I guess.
>
> p.s.  We might also want to propose a rule that says any new releases
> of a commons component have to be done in the org.apache.commons
> groupId, but that's another issue.
>
> p.p.s. If anyone cares to restate this rule, please feel free to do
> so.  I may not have addressed certain "gotchas", but the general idea
> is presented.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

jodastephen
In reply to this post by James Carman
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 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
compatible.

It is also possible for a major version to remove just one or two long
deprecated methods. In this case, the pain of a package name change is
outweighed by the small likelihood of problems.

Finally, there are cases where the objects referred to are significant
value types that are widely used. In this case, changing the package
name is problematic as it causes other libraries that expose those
value types onwards to have problems.

As an example, Joda-Time may soon have a v2.0. Changing the package
name would be necessary if there was major incompatibility. However,
in the plan, Joda-Time 2.0 includes Java 5 generics support which is
99% compatible, and the removal of just a handful of long deprecated
methods. Furthermore, since many, many other systems use Joda-Time in
their APIs, having two versions out there simply wouldn't work.

By counter example, having two versions of a standalone utility like
StringUtils makes no difference, and having a package name change
might make sense in these cases.

As such, were I to be voting, I would vote -1.
Although I do understand the sentiment, more subtlty is required here
- package name changes are sometimes necessary, but must be treated
with care.
Stephen


On 24 November 2010 15:36, James Carman <[hidden email]> 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 that the component's
> situation is unique and not affected by the issues that this rule
> tries to address.  This is to avoid re-hashing this argument all the
> time.  If a component wants to break the rule, then they should think
> through the arguments (read the Wiki page first) and carefully
> consider why they feel they are unique and unaffected by the issues.
> So, here's the rule:
>
> 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 rule
> [ ] -1 - do not accept this as a rule
>
> Note that we already have a "rule" that says if you're going to break
> binary compatibility, you have to change the major version number, so
> this rule picks up where that one leaves off I guess.
>
> p.s.  We might also want to propose a rule that says any new releases
> of a commons component have to be done in the org.apache.commons
> groupId, but that's another issue.
>
> p.p.s. If anyone cares to restate this rule, please feel free to do
> so.  I may not have addressed certain "gotchas", but the general idea
> is presented.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

James Carman
On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
<[hidden email]> 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
> compatible.
>
> It is also possible for a major version to remove just one or two long
> deprecated methods. In this case, the pain of a package name change is
> outweighed by the small likelihood of problems.
>
> Finally, there are cases where the objects referred to are significant
> value types that are widely used. In this case, changing the package
> name is problematic as it causes other libraries that expose those
> value types onwards to have problems.
>
> As an example, Joda-Time may soon have a v2.0. Changing the package
> name would be necessary if there was major incompatibility. However,
> in the plan, Joda-Time 2.0 includes Java 5 generics support which is
> 99% compatible, and the removal of just a handful of long deprecated
> methods. Furthermore, since many, many other systems use Joda-Time in
> their APIs, having two versions out there simply wouldn't work.
>

All of these examples would be situations where you'd make the case
that this is an exception, which is allowed by the "rule".

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Gary Gregory
In reply to this post by James Carman
+1

Gary

On Nov 24, 2010, at 7:36, "James Carman" <[hidden email]> 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 that the component's
> situation is unique and not affected by the issues that this rule
> tries to address.  This is to avoid re-hashing this argument all the
> time.  If a component wants to break the rule, then they should think
> through the arguments (read the Wiki page first) and carefully
> consider why they feel they are unique and unaffected by the issues.
> So, here's the rule:
>
> 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 rule
> [ ] -1 - do not accept this as a rule
>
> Note that we already have a "rule" that says if you're going to break
> binary compatibility, you have to change the major version number, so
> this rule picks up where that one leaves off I guess.
>
> p.s.  We might also want to propose a rule that says any new releases
> of a commons component have to be done in the org.apache.commons
> groupId, but that's another issue.
>
> p.p.s. If anyone cares to restate this rule, please feel free to do
> so.  I may not have addressed certain "gotchas", but the general idea
> is presented.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

James Carman
In reply to this post by sebb-2-2
On Wed, Nov 24, 2010 at 11:07 AM, sebb <[hidden email]> 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 rule
>> [X] -1 - do not accept this as a rule
>
> Components should be allowed to increment the major version even if
> there is no binary incompatibility.
>
> A package name change forces total binary incompatibilty.
>

Please keep in mind that this "rule" is made to be able to be broken
for the special cases.  It's intended to be in place for the general
case, which most components/releases would fall under.  This is to
avoid having to argue this same point all the time.  We all have
better things to do.  If we can just say "you break the
version/package/artifact rule" with this release (and point to the
Wiki page), then there really is no discussion, unless the component
feels that it is in a special case.  Also, the [VOTE] thread could
have the justification in it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

James Carman
In reply to this post by James Carman
On Wed, Nov 24, 2010 at 10:36 AM, James Carman
<[hidden email]> wrote:
>
> [ ] +1 - accept this as a rule
> [ ] -1 - do not accept this as a rule
>

Here's my +1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Phil Steitz
In reply to this post by jodastephen
On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
<[hidden email]>wrote:

> 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 significant
> incompatibility, but a major version change might not cause such
> incompatibility.
>
> 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
> compatible.
>
> It is also possible for a major version to remove just one or two long
> deprecated methods. In this case, the pain of a package name change is
> outweighed by the small likelihood of problems.
>
> Finally, there are cases where the objects referred to are significant
> value types that are widely used. In this case, changing the package
> name is problematic as it causes other libraries that expose those
> value types onwards to have problems.
>

I have been worrying about this re [pool] where we made the decision to
repackage for 2.0.  My perhaps naive assumption is that users who are just
using the interface definitions or constants can continue to depend on the
1.x versions.  Do you see a problem with this?

>
> As an example, Joda-Time may soon have a v2.0. Changing the package
> name would be necessary if there was major incompatibility. However,
> in the plan, Joda-Time 2.0 includes Java 5 generics support which is
> 99% compatible, and the removal of just a handful of long deprecated
> methods. Furthermore, since many, many other systems use Joda-Time in
> their APIs, having two versions out there simply wouldn't work.
>
> By counter example, having two versions of a standalone utility like
> StringUtils makes no difference, and having a package name change
> might make sense in these cases.
>
> As such, were I to be voting, I would vote -1.
> Although I do understand the sentiment, more subtlty is required here
> - package name changes are sometimes necessary, but must be treated
> with care.
> Stephen
>
>
> On 24 November 2010 15:36, James Carman <[hidden email]>
> 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 that the component's
> > situation is unique and not affected by the issues that this rule
> > tries to address.  This is to avoid re-hashing this argument all the
> > time.  If a component wants to break the rule, then they should think
> > through the arguments (read the Wiki page first) and carefully
> > consider why they feel they are unique and unaffected by the issues.
> > So, here's the rule:
> >
> > 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 rule
> > [ ] -1 - do not accept this as a rule
> >
> > Note that we already have a "rule" that says if you're going to break
> > binary compatibility, you have to change the major version number, so
> > this rule picks up where that one leaves off I guess.
> >
> > p.s.  We might also want to propose a rule that says any new releases
> > of a commons component have to be done in the org.apache.commons
> > groupId, but that's another issue.
> >
> > p.p.s. If anyone cares to restate this rule, please feel free to do
> > so.  I may not have addressed certain "gotchas", but the general idea
> > is presented.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Ralph Goers
In reply to this post by James Carman

On Nov 24, 2010, at 8:18 AM, James Carman wrote:

> On Wed, Nov 24, 2010 at 11:11 AM, Stephen Colebourne
> <[hidden email]> 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
>> compatible.
>>
>> It is also possible for a major version to remove just one or two long
>> deprecated methods. In this case, the pain of a package name change is
>> outweighed by the small likelihood of problems.
>>
>> Finally, there are cases where the objects referred to are significant
>> value types that are widely used. In this case, changing the package
>> name is problematic as it causes other libraries that expose those
>> value types onwards to have problems.
>>
>> As an example, Joda-Time may soon have a v2.0. Changing the package
>> name would be necessary if there was major incompatibility. However,
>> in the plan, Joda-Time 2.0 includes Java 5 generics support which is
>> 99% compatible, and the removal of just a handful of long deprecated
>> methods. Furthermore, since many, many other systems use Joda-Time in
>> their APIs, having two versions out there simply wouldn't work.
>>
>
> All of these examples would be situations where you'd make the case
> that this is an exception, which is allowed by the "rule".
>

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 occurs.

Ralph


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Ralph Goers
In reply to this post by James Carman

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 that the component's
> situation is unique and not affected by the issues that this rule
> tries to address.  This is to avoid re-hashing this argument all the
> time.  If a component wants to break the rule, then they should think
> through the arguments (read the Wiki page first) and carefully
> consider why they feel they are unique and unaffected by the issues.
> So, here's the rule:
>
> 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 rule
> [ ] -1 - do not accept this as a rule
>

-1 for the same reasons stated by Stephen and sebb.  If this was changed to be based on binary compatibility breakage I would vote +1.

Ralph


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Niall Pemberton
In reply to this post by James Carman
On Wed, Nov 24, 2010 at 3:36 PM, James Carman
<[hidden email]> 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 that the component's
> situation is unique and not affected by the issues that this rule
> tries to address.  This is to avoid re-hashing this argument all the
> time.  If a component wants to break the rule, then they should think
> through the arguments (read the Wiki page first) and carefully
> consider why they feel they are unique and unaffected by the issues.
> So, here's the rule:
>
> 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.

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
confusion. The decisions for each influence each, but IMO they need to
be considered separately.

So -1 from me.

Niall


> [ ] +1 - accept this as a rule
> [ ] -1 - do not accept this as a rule
>
> Note that we already have a "rule" that says if you're going to break
> binary compatibility, you have to change the major version number, so
> this rule picks up where that one leaves off I guess.
>
> p.s.  We might also want to propose a rule that says any new releases
> of a commons component have to be done in the org.apache.commons
> groupId, but that's another issue.
>
> p.p.s. If anyone cares to restate this rule, please feel free to do
> so.  I may not have addressed certain "gotchas", but the general idea
> is presented.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

James Carman
In reply to this post by Ralph Goers
On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
<[hidden email]> 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 occurs.
>

Ok, so how about we change the rule?  We could say "if the binary
compatibility is broken, then the package/artifactId must change."
Again, this rule can be broken if a component feels they need to do so
and they provide a very good reason. :)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

James Carman
In reply to this post by Niall Pemberton
On Wed, Nov 24, 2010 at 12:16 PM, Niall Pemberton
<[hidden email]> 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
> confusion. The decisions for each influence each, but IMO they need to
> be considered separately.
>

I'm trying to come up with a general rule or a "best practice" here.
Since we *are* one project, we should try to achieve some consistency
among our subcomponents.  Is there no common ground with this
package/artifactId thing we can agree upon, at least "in general"?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Luc Maisonobe
In reply to this post by James Carman
Le 24/11/2010 20:43, James Carman a écrit :
> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
> <[hidden email]> 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 occurs.
>>
>
> Ok, so how about we change the rule?  We could say "if the binary
> compatibility is broken, then the package/artifactId must change."

+1 for the rule as stated here.

Luc

> Again, this rule can be broken if a component feels they need to do so
> and they provide a very good reason. :)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Oliver Heger-3
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
>> <[hidden email]>  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 occurs.
>>>
>>
>> Ok, so how about we change the rule?  We could say "if the binary
>> compatibility is broken, then the package/artifactId must change."
>
> +1 for the rule as stated here.
>
> Luc

+1 I would also sign this.

Oliver

>
>> Again, this rule can be broken if a component feels they need to do so
>> and they provide a very good reason. :)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Jörg Schaible
In reply to this post by Luc Maisonobe
Luc Maisonobe wrote:

> Le 24/11/2010 20:43, James Carman a écrit :
>> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
>> <[hidden email]> 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
>>> occurs.
>>>
>>
>> Ok, so how about we change the rule?  We could say "if the binary
>> compatibility is broken, then the package/artifactId must change."
>
> +1 for the rule as stated here.

+1

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Niall Pemberton
In reply to this post by James Carman
On Wed, Nov 24, 2010 at 7:43 PM, James Carman
<[hidden email]> wrote:

> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
> <[hidden email]> 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 occurs.
>>
>
> Ok, so how about we change the rule?  We could say "if the binary
> compatibility is broken, then the package/artifactId must change."
> Again, this rule can be broken if a component feels they need to do so
> and they provide a very good reason. :)

How about "if a component decides on a package rename, then the maven
artifactId must change"?

If a component breaks binary compatibility and chooses not to do a
package rename then changing the maven artifact doesn't help in any
way and will just mean additoinal pom config might be required to
exclude the old artifact.

Niall

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

James Carman
They would need to change together to be of any use obviously.
On Nov 24, 2010 3:55 PM, "Niall Pemberton" <[hidden email]>
wrote:
> On Wed, Nov 24, 2010 at 7:43 PM, James Carman
> <[hidden email]> wrote:
>> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
>> <[hidden email]> 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 occurs.

>>>
>>
>> Ok, so how about we change the rule?  We could say "if the binary
>> compatibility is broken, then the package/artifactId must change."
>> Again, this rule can be broken if a component feels they need to do so
>> and they provide a very good reason. :)
>
> How about "if a component decides on a package rename, then the maven
> artifactId must change"?
>
> If a component breaks binary compatibility and chooses not to do a
> package rename then changing the maven artifact doesn't help in any
> way and will just mean additoinal pom config might be required to
> exclude the old artifact.
>
> Niall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

Ralph Goers
In reply to this post by James Carman

On Nov 24, 2010, at 11:43 AM, James Carman wrote:

> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
> <[hidden email]> 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 occurs.
>>
>
> Ok, so how about we change the rule?  We could say "if the binary
> compatibility is broken, then the package/artifactId must change."
> Again, this rule can be broken if a component feels they need to do so
> and they provide a very good reason. :)

I would agree with this. However, I would suggest that if the package and artifactId change the version MUST change.

Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Accept the package name/artifactId guideline as a "rule"...

James Carman
That's already part of the binary compatibility rule
On Nov 24, 2010 4:31 PM, "Ralph Goers" <[hidden email]> wrote:
>
> On Nov 24, 2010, at 11:43 AM, James Carman wrote:
>
>> On Wed, Nov 24, 2010 at 12:00 PM, Ralph Goers
>> <[hidden email]> 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 occurs.
>>>
>>
>> Ok, so how about we change the rule? We could say "if the binary
>> compatibility is broken, then the package/artifactId must change."
>> Again, this rule can be broken if a component feels they need to do so
>> and they provide a very good reason. :)
>
> I would agree with this. However, I would suggest that if the package and
artifactId change the version MUST change.
>
> Ralph
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
12