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

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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

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

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