[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] Re: [jgit-dev] API and versioning
|
söndagen den 17 januari 2010 11.45.43 skrev Ferry Huberts:
> On 01/17/2010 12:36 AM, Shawn O. Pearce wrote:
> > Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> wrote:
> >> Should we declare version dependencies at the bundle or package level?
> >> I'm not OSGi-fluent enough to tell the real difference, but bundle level
> >> seems to match how we define versions better, i.e. we don't state
> >> anywhere that this package is version 0.6.0, we do that at the bundle
> >> level and I think that is the way most projects work. My feeling is that
> >> the package version dependency in OSGi is for those that actually assign
> >> versions at the package level.
> >
> > I think what we should do right now is:
> >
> > Given a release numbering of 0.x.y:
> >
> > - If x changes, APIs can be removed or semantics changed.
> > Applications linking against 0.x should take care before
> > moving to another 0.x release.
> >
> > - If x stays same but y changes, no APIs have been removed, and no
> > semantic changes have been made. New APIs however can be added.
> >
> > That means in practice that other bundles importing JGit should use
> > an import rule like ";version=[0.6.0,0.7.0)".
> >
> > This also means we have to be very careful about using git describe
> > to create a snapshot version number, basically tools/version.sh
> > is wrong.
> >
> > Whether or not we import using Require-Bundle or Import-Package
> > doesn't much matter. But Import-Package is I think preferred
> > because...
> >
> >> Is the ability to split bundles in the future a reason set requirements
> >> at the package level?
> >
> > I think that's the only reason for package level vs. bundle level.
>
> This proposal is not following OSGi versioning rules and common practices,
> so maybe that's asking for trouble.
>
> Checkout the OSGi spec for platform 4.2 at
> http://www.osgi.org/Download/File?url=/download/r4v42/r4.core.pdf
>
> On page 32 you'll see the definition for the version number.
>
> In your proposal you're allowing api changes in minor releases, which is
> not a common pratice. In light of still being in development I can
> understand it though.
>
> Maybe a better idea would be to allow new apis but no api changes or
> removals in minor releases (shift your proposal from minor to major
> versions)
I think we can change API' on minor releass before the 0.1 release? Otherwise
we would be at version 314.1.5 now.
>
> Also, be aware that 0.6.0.rc1 is _newer_ than 0.6.0
In other words our release plans should be revised since the current version
numer is 0.6.0.qualifier, which translates to an actual build number of
0.6.0.201001162204. The next possible version is 0.6.1, but for official
planning 0.7.0 seems better.
Here are our previous drops, i.e. The first PDE-builds where 0.3.0, I think.
0.1.1
0.2
0.2.1
0.2.2
0.2.2.200709060913
0.2.2.200709172216
0.2.99.200709172321 <-- 99 = dev
0.2.99.200709200123
0.3.0
0.3.0.200801200715 (came after 0.3.0)
0.3.1
0.3.1.200804081831
0.3.1.200804082056
0.3.1.200804271206
0.3.1.200805192137
0.3.1.200805231331
0.3.1.200805250051
0.3.1.200805281647
0.3.1.200805290117
0.3.1.200806012354
0.3.1.200806042315
0.3.1.200806102352
0.3.1.200807010057
0.3.1.200807080002
0.3.1.200807092245 (PDE builds and semi-secret update site from ~here)
0.3.1.200807092253
0.3.1.200807092357
0.3.1.200807100122
0.3.1.200807111226
0.3.1.200807181307
0.3.1.200808111543
0.3.1.200808150007
0.3.1.200808200052
0.3.1.200808222117
0.3.1.200808222256
0.3.1.200808240152
0.3.1.200808280019
0.3.1.200808290018
0.3.1.200809032102
0.3.1.200809050127
0.3.1.200809072338
0.3.1.200809180025
0.3.1.200809201133
0.3.1.200809210023
0.3.1.200809242127
0.3.1.200809250108
0.3.1.200810030825
0.3.1.200810181149
0.3.1.200810240005
0.3.1.200811170748
0.3.1.200811260008
0.4.0
0.4.0.200901041117 (came after 0.4.0)
0.4.0.200901272110
0.4.0.200901290805
0.4.0.200902052244
0.4.0.200902110811
0.4.0.200902190113
0.4.0.200903070135
0.4.0.200903151305
0.4.0.200903170104
0.4.0.200903192117
0.4.0.200903200852
0.4.0.200903271225
0.4.0.200904052315
0.4.0.200904100523
0.4.0.200904190103
0.4.0.200904261421
0.4.0.200904301808
0.4.0.200905040051
0.4.0.200905050048
0.4.0.200905140116
0.4.0.200906121938
0.4.0.200906160801
0.4.0.200906200212
0.4.9 (developement baseline for changing the package names, i.e. the egit
plugin moved to Ecclipse).
0.4.9.200906240051 (dev build)
0.5.0
0.5.0.200908130032 (came after 0.5.0)
0.5.0.200908141101
0.5.0.200908282229
0.6.0.200911171911 (here we have swiched JGit to eclipse too). There was not
new functionality so therefore I did not care to relase a 0.6.0 at the time)
0.6.0.200912061443
0.6.0.201001122046
0.6.0.201001161941
0.6.0.201001162204
-- robin
