Torsten Curdt apache.org> writes:
> > I really wonder why this should be a concern of the actual component at all.
> > A component is an encapsulated piece of software with a well-defined
> > interface (here API). If there are problems in the environment in using this
> > component or looking it
On 11/7/06, Joerg Heinicke <[EMAIL PROTECTED]> wrote:
Stephen Colebourne btopenworld.com> writes:
> PROPOSAL:
> The major version number of a component, where it is greater than 1,
> shall be included in the package name.
I really wonder why this should be a concern of the actual component at
Stephen Colebourne btopenworld.com> writes:
> PROPOSAL:
> The major version number of a component, where it is greater than 1,
> shall be included in the package name.
I really wonder why this should be a concern of the actual component at all. A
component is an encapsulated piece of software w
Stephen Colebourne wrote on Sunday, October 29, 2006 12:35 PM:
> PROPOSAL:
> The major version number of a component, where it is greater than 1,
> shall be included in the package name.
>
[snip]
>
> This proposal is about making upgrades *predicatable* at the
> expense of
> a small amount of pai
On 11/1/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
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 seco
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 chang
On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
This proposal is about making upgrades *predicatable* at the expense of
a small amount of pain. I know that most of us don't really like it, but
I contend that there is no alternative other than to inflict pain on
users of commons over
On 10/30/06, Luc Maisonobe <[EMAIL PROTECTED]> wrote:
(I'm not sure I allowed to express this opinion as I am only a new
contributor, please ignore this message if you consider this a reserved
topic).
Absolutely you're allowed - its a public mailing list - there aren't
any "reserved topics" he
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 manda
On 10/30/06, Luc Maisonobe <[EMAIL PROTECTED]> wrote:
(I'm not sure I allowed to express this opinion as I am only a new
contributor, please ignore this message if you consider this a reserved
topic).
Please, comment away. All topics are open, and this one especially so
given that it's talking
someone said:
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"
This may or may not be true and it also depend on how the product is
used. Some power users may consider an apparent min
On 10/30/06, Sandy McArthur <[EMAIL PROTECTED]> wrote:
On 10/30/06, Henri Yandell <[EMAIL PROTECTED]> 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
> > >
On 10/30/06, Henri Yandell <[EMAIL PROTECTED]> 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-back
On 10/30/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 10/30/06, Henri Yandell <[EMAIL PROTECTED]> 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
> > >
On 10/30/06, Henri Yandell <[EMAIL PROTECTED]> 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-bac
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 manda
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 manda
gt; To: Jakarta Commons Developers List
> Subject: Re: [PROPOSAL] Major versions require package name change
>
> On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> > PROPOSAL:
> > The major version number of a component, where it is greater than 1,
> > sha
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 mand
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
> co
On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
PROPOSAL:
The major version number of a component, where it is greater than 1,
shall be included in the package name.
I gotta disagree with this.
If we want to come up with the notion of a "super" version, something
that is more broad
Torsten
I dont get the analogy either - I didnt see how it helped prove your point. I
understand your arguments though, and I can see your point, but I still can't
see any convincing arguments for mandating this type of approach. Best left to
the individual project maintainers, IMHO.
"Jakarta
Torsten
I dont get the analogy either - I didnt see how it helped prove your point. I
understand your arguments though, and I can see your point, but I still can't
see any convincing arguments for mandating this type of approach. Best left to
the individual project maintainers, IMHO.
"Jakarta
On 10/30/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 10/30/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> > There are clearly good reasons / circumstances to take the approach
> > you suggest, but it is a user unfriendly approach. As a user I like to
> > try out new versions by dropping in
On 10/30/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> There are clearly good reasons / circumstances to take the approach
> you suggest, but it is a user unfriendly approach. As a user I like to
> try out new versions by dropping in a new jar - before taking the
> decision to upgrade. This appr
I think the point is that we don't think this should be mandated and
up to the individual project teams to decide what they want to do. I
would agree that this option should be standardized (appending the
major release version number to the package name) so that folks know
what's going on if it d
There are clearly good reasons / circumstances to take the approach
you suggest, but it is a user unfriendly approach. As a user I like to
try out new versions by dropping in a new jar - before taking the
decision to upgrade. This approach rules that out and it wouldn't
surprise me if users starte
I agree. I don't think we should mandate this either.
On 10/29/06, Rory Winston <[EMAIL PROTECTED]> wrote:
That should be "an appropriate solution *for everybody*"
Rory Winston wrote:
> +1
>
> I agree this is an issue which package maintainers will need to
> consider when making major releases
That should be "an appropriate solution *for everybody*"
Rory Winston wrote:
+1
I agree this is an issue which package maintainers will need to
consider when making major releases. I dont believe that mandating
package name changes is an appropriate solution.
Niall Pemberton wrote:
On 10/2
+1
I agree this is an issue which package maintainers will need to consider
when making major releases. I dont believe that mandating package name
changes is an appropriate solution.
Niall Pemberton wrote:
On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
PROPOSAL:
The major versio
On 10/29/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
PROPOSAL:
The major version number of a component, where it is greater than 1,
shall be included in the package name.
EXAMPLE:
org.apache.commons.pool - version 1.x line
org.apache.commons.pool2 - version 2.x line
RATIONALE:
Java has no
PROPOSAL:
The major version number of a component, where it is greater than 1,
shall be included in the package name.
EXAMPLE:
org.apache.commons.pool - version 1.x line
org.apache.commons.pool2 - version 2.x line
RATIONALE:
Java has no mechanism for handling different versions of the same
li
32 matches
Mail list logo
