Subject:Re: [equinox-dev] .qualifier for export package?
Wouldn't importing a micro version cause the client
Thomas Watson [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
09/09/2008 09:16 AM
Please respond to
Equinox development mailing list equinox-dev@eclipse.org
To
Equinox development mailing list equinox-dev@eclipse.org
cc
Subject
Re: [equinox-dev] .qualifier for export package
Subject
Re: [equinox-dev]
.qualifier for export
package
: [equinox-dev] .qualifier for export package?
For the most part I agree. But I do think there is value in versioning API
packages that contain not only pure specification but also implementation.
One real example is the OSGi package org.osgi.util.tracker package. This
package contains
Date:
09/05/2008 11:00 AM
Subject:
Re: [equinox-dev] .qualifier for export package?
We have qualifiers on bundles to support the notion of provisioning
"line-ups" (aka features) that list p
st equinox-dev@eclipse.org
Date:
09/05/2008 04:32 AM
Subject:
Re: [equinox-dev]
.qualifier for export
package?
I'm certainly sympathetic to you thinking here.
Having
evelopment
mailing list equinox-dev@eclipse.org
Date:
2008/09/05 04:32 AM
Subject:
Re: [equinox-dev]
.qualifier for export
package?
I'm certainly sympathetic to you thinking he
Jeff McAffer
[EMAIL PROTECTED]
To:
Equinox development
mailing list equinox-dev@eclipse.org
Date:
2008/09/03 06:16 AM
Subject:
Re: [equinox-dev]
.qualifier
|
|
|
| Subject: |
|
|
|Re: [equinox-dev] .qualifier for export package
equinox-dev@eclipse.org
Date:
09/05/2008 04:32 AM
Subject:
Re: [equinox-dev] .qualifier for export package?
I'm certainly sympathetic to you thinking here. Having qualifiers in
import statements is ugly at best. The challenge is that in the dev cycle
the API of something may change many many
development mailing list equinox-dev@eclipse.org
Date:
2008/09/05 10:18 AM
Subject:
Re: [equinox-dev] .qualifier for export package?
Without some sort of increasing version number on the packages, p2
for example, will have a hard time figuring out what to give you
cause everything will look
/[EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
09/05/2008 07:50 AM
Subject:
Re: [equinox-dev] .qualifier for export package?
If I understand #2 correctly, then you want a controlled version practice
during the development cycle. This is challenging since
equinox-dev@eclipse.org
Date: 09/05/2008 09:40 AM
Subject:Re: [equinox-dev] .qualifier for export package
@eclipse.org
cc
Subject
Re: [equinox-dev] .qualifier for export package?
I'm certainly sympathetic to you thinking here. Having qualifiers in
import statements is ugly at best. The challenge is that in the dev cycle
the API of something may change many many times. This would lead to quite
Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Thomas Watson/Austin/[EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/05 12:03 PM
Subject:
Re: [equinox-dev] .qualifier for export package
Subject:Re: [equinox-dev] .qualifier for export package?
We have qualifiers on bundles to support the notion of provisioning
From:
Jeff McAffer [EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/03 06:16 AM
Subject:
Re: [equinox-dev] .qualifier for export package?
I understand your hestiation and actually agree with you from the
released code point of view. However, we
: [equinox-dev] .qualifier for export package?
On Sun, Aug 31, 2008 at 5:53 AM, Jeff McAffer [EMAIL PROTECTED] wrote:
As version numbers on packages become more prevalent does it start making
sense to use
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Thomas Watson/Austin/[EMAIL PROTECTED]
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2008/09/02 10:45 AM
Subject:
Re: [equinox-dev] .qualifier for export package
API Tooling also has
items in plan that deal with package versioning, but that will be post
M2
FYI - plans for package version support in API tooling have been reduced.
Currently, there is nothing on the draft plan due to resources available
to do the work, and the fact that SDK plug-in
Here are some obvious questions:
* How are @since tags formatted to indicate that the version number
corresponds to packages vs. bundles?
If there is a package version then the @since should always reference
the package version exported in my opinion.
* How are initial package versions
Darin Wright
Eclipse Debug Lead,
Rational Team,
IBM Canada
(204)938-8051
[EMAIL PROTECTED] wrote on 09/02/2008 01:59:00 PM:
Here are some obvious questions:
* How are @since tags formatted to indicate that the version number
corresponds to packages vs. bundles?
If there is a
Right, but since package versions will now evolve independently of
bundle
versions, should the package name also appear in the @since tag - like
@since org.eclipse.jdt.debug.model 3.4. Else, when just looking at the
Javadoc, consumers of an API will not know if they need a required
Right, but since package versions will now evolve independently of
bundle
versions, should the package name also appear in the @since tag - like
@since org.eclipse.jdt.debug.model 3.4. Else, when just looking at
the
Javadoc, consumers of an API will not know if they need a required
On Sun, Aug 31, 2008 at 5:53 AM, Jeff McAffer [EMAIL PROTECTED] wrote:
As version numbers on packages become more prevalent does it start making
sense to use .qualifier on them in addition to bundle version numbers? The
logic here is the same as for bundles. we rev the version number of the
25 matches
Mail list logo
