[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?


Yes, none of the p2 bundles contain any API today, so strictly speaking the major version shouldn't increment. However, since these bundles currently *only* contain provisional API, then anyone relying on the 1.x version of these bundles is guaranteed to be broken by the package renaming and transition to real API. We know we have existing clients of the provisional API who will certainly be broken so moving to 2.0 bundle versions would reflect that (only for those bundles graduating from provisional to real API). If we had bundles with a mixture of provisional and non-provisional API then that certainly wouldn't be an option. We're in somewhat uncharted territory with having a large provisional API with existing clients in the field that we're transitioning over to mature API.

On the flip side, we don't want to break anyone with a version change that wouldn't already be broken, so I'm trying to think if there are people who would be requiring our bundles but not referencing any of our existing code (provisional or internal). Are there p2 consumers out there with thoughts on this?

John




Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

10/29/2009 09:25 AM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject
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



Inactive hide details for Ian Bull ---10/28/2009 09:49:53 PM---+1, I think 2.0 makes sense. Although, theoretically this shouldIan 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.

Inactive hide details for Susan Franklin McCourt ---10/28/2009 06:06:35 PM---I'm experimenting/playing with wild refactorings iSusan 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

From:

Susan Franklin McCourt <
susan_franklin@xxxxxxxxxx>

To:

P2 developer discussions <
p2-dev@xxxxxxxxxxx>

Date:

10/28/2009 06:06 PM

Subject:

[p2-dev] what @since tag to use when the API graduates?





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

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev