I'm pretty sure I agree. Marketing numbers are independent of the
bundle/feature numbers. The only challenge is that our community has
been trained to believe that N+1 breaks N. So you have a marketing
problem if you increment (or dont' increment) to match the standard
functional policy. Personally I think there are real cases where it
makes sense to deviate but you should do so knowingly.
Jeff
Mark Rogalski wrote:
Well stated Tom.
I'm not sure if there are any conventions here. So
just
take my comments as my own opinion for now.
In my opinion the release version number is largely for marketing. I
think
this is one of the reasons the release train names stay away from
numbered
names. Numbered release names imply some level of change and
compatibility
depending on the type of version change (major, minor, micro etc.). If
your release name (version) must reflect your level of API
compatibility
then you would be forced to increase the major/minor/micro version
according
to the greatest change going into all your bundles included in the
release.
Note that this is not as simple as picking the highest bundle version
in
your release. Imagine the following release of XYZ that has three
bundles
A, B, C:
XYZ: version 1.0.0
A: 1.0.0
B: 1.0.0
C: 1.0.0
Now imagine A had major changes to its API that broke compatibility and
B and C only had minor bug fixes:
XYZ: version 2.0.0
A: 2.0.0
B: 1.0.1
C: 1.0.1
You would be forced to move the release version up to 2.0. No for the
next
release imagine B had the breaking changes and A and C only had bug
fixes:
XYZ: version 3.0.0
A: 2.0.1
B: 2.0.0
C: 1.0.1
You would be forced to move the release version of XYZ release up to
3.0.0
because of the breaking change to B from the XYX 2.0.0 release to the
XYX
3.0.0 release. Perhaps that is an acceptable policy but I don't think
it
applies in a lot of cases. Perhaps the breaking change to B was minor
and
really only affected 1% of your clients. The other 99% of the clients
run
just fine. Does this really warrant a major version change of your
release
of XYZ? From the community point of view they may say "look at them
XYZ folks breaking us again with a major version change in their
release"
when in reality you may have affected a very small set of developers
and
you could provide a very small migration guide to get them up and
running
quickly on your new release.
>From a marketing point of view do you really want to call such a
release
a major version change? In my opinion, no. I think major version
changes
in a release name should only happen when there is a major shift in the
release. For example, the move to 3.0 in the Eclipse platform when the
move was made to use OSGi. In my opinion API contracts should only be
expressed
in such things as bundle versions and package versions. I think trying
to convey API contracts at a release level is far to coarse grained to
be very useful.
Tom
Scott
Lewis ---06/24/2009 10:04:15 AM---I would like to follow up on/discuss
this question a little bit.
I would like to follow up on/discuss this question a little bit.
Let's say a given project exposes 3 APIs: A, B, C. Assume
all of
these are non-provisional. Assume to start that all are at version
1.0.0. Assume also that the project is at version 1.0.0.
If the bundle(s) that constitute A go through a major upgrade, and A's
version number changes to 2.0.0, while the other two go through minor
upgrades (e.g. 1.1.0), what does this imply (or require) in terms of
the
project-level versioning? I understand that technically/API tools
the
project-level version can be anything the project wants, but as far as
I've seen, no Eclipse project has (yet) had major version changes of
individual bundles/APIs within a minor project-level version change
(e.g. 1.1.0). I also understand that the typical is the reverse...i.e.
the project-level version changes moving faster/larger than the
bundle-level changes...but what, if any, conventions/rules exist around
this situation?
Thanks,
Scott
Mark Rogalski wrote:
>
> Whether a formal project release review is required depends on the
> version number of the project rather than it's content. I think
the
> real question is whether the major upgrade of an internal bundle
> necessitates a change in the encompassing project's versioning.
This
> probably needs to be determined on a case by case basis. Will
the
> internal bundle upgrade break any compatibilities in ECF?
> If not, then there is probably no need to wait for a major version
> change of ECF. If yes, then the extent of the incompatibilities
need
> to be weighed.
>
>
>
>
> *Markus Alexander Kuppe <rt-pmc_eclipse.org@xxxxxxxxxxx>*
> Sent by: rt-pmc-bounces@xxxxxxxxxxx
>
> 06/09/2009 10:30 AM
> Please respond to
> Runtime Project PMC mailing list <rt-pmc@xxxxxxxxxxx>
>
>
>
> To
> rt-pmc@xxxxxxxxxxx
> cc
> ecf-dev@xxxxxxxxxxx
> Subject
> [rt-pmc] Bundle major versions and project major release
>
>
>
>
>
>
>
>
>
> Hi rt-pmc,
>
> during today's ECF con call the question came up if an increase of
a
> single bundle major version automatically and always causes the
> requirement to do a project major release.
>
> E.g. one example would be that at some points in time ECF
definitely
> wants to move upwards from jSLP [1] 1.0 to 2.0 (the fact that jSLP
2.0
> is going to be hosted at Apache may be out of this scenario) which
> probably won't be in sync with our "regular" release planing.
So do we
> have to postpone the bundle upgrade until we do ECF 4.0?
>
> Cheers
> Markus
>
> [1] http://jslp.sf.net
<http://jslp.sf.net/>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
|