[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] what @since tag to use when the API graduates?
|
Is p2 going to version the API packages individually? If so then i would expect the @since tag to use the package version, not the bundle version. In that case this would all be new API and the package version should start at 1.0.0 in my opinion.
I'm not convinced the bundle versions should move up to version 2.0 because we have removed non-API (provisional stuff). In reality we are only adding new API so the minor version of the bundle would increase in that case, correct?
Tom
Ian Bull ---10/28/2009 09:49:53 PM---+1, I think 2.0 makes sense. Although, theoretically this should be on a bundle by bundle basis I assume? If nothing (API wise
![]()
From: | ![]()
Ian Bull <irbull@xxxxxxxxxxxxxxxxx> |
![]()
To: | ![]()
P2 developer discussions <p2-dev@xxxxxxxxxxx> |
![]()
Cc: | ![]()
p2-dev-bounces@xxxxxxxxxxx |
![]()
Date: | ![]()
10/28/2009 09:49 PM |
![]()
Subject: | ![]()
Re: [p2-dev] what @since tag to use when the API graduates? |
+1, I think 2.0 makes sense. Although, theoretically this should be on a bundle by bundle basis I assume? If nothing (API wise) changes in a bundle, then it shouldn't get moved to 2.0, right? Essentially we should follow the API / Version conventions on a per bundle basis, not a component basis.
cheers,
ian
On Wed, Oct 28, 2009 at 6:24 PM, Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx> wrote:
the @since should follow the version of the manifest.
>From there the question is what will be the version of p2 in 3.6? I would say 2.0 since we are introducing breaking changes by removing some provisional API.
Susan Franklin McCourt ---10/28/2009 06:06:35 PM---I'm experimenting/playing with wild refactorings in the p2 UI to see if there is a "bare minimum" set of UI classes that would
I'm experimenting/playing with wild refactorings in the p2 UI to see if there is a "bare minimum" set of UI classes that would make sense as API. This mainly involves the operations and the policy objects. In moving classes around to API-named packages, I get API tooling @since tag errors because the tooling expects the @since tags to match the manifest version. However, so far I have been using Eclipse release conventions.
So...I have methods that currently use
@since 3.4
I was assuming that when things actually graduate, we would use
@since 3.6
but that would require a bunch of API problem filters because the tooling (rightfully?) expects to see
@since 1.1
We'll have to have a common strategy for this when we merge the branch back. Thoughts?
susan_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
![GIF image](gifnrOgJPu4sa.gif)
![GIF image](gifFoRulY849j.gif)