Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] Bundle major versions and project major release


Well stated Tom.



Thomas Watson/Austin/IBM@IBMUS
Sent by: rt-pmc-bounces@xxxxxxxxxxx

06/24/2009 10:42 AM

Please respond to
Runtime Project PMC mailing list <rt-pmc@xxxxxxxxxxx>

To
Runtime Project PMC mailing list <rt-pmc@xxxxxxxxxxx>
cc
Subject
Re: [rt-pmc] Bundle major versions and project major release





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



Inactive hide details for Scott Lewis ---06/24/2009 10:04:15 AM---I would like to follow up on/discuss this question a little bScott Lewis ---06/24/2009 10:04:15 AM---I would like to follow up on/discuss this question a little bit.

From:

Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>

To:

Runtime Project PMC mailing list <rt-pmc@xxxxxxxxxxx>

Cc:

ecf-dev@xxxxxxxxxxx

Date:

06/24/2009 10:04 AM

Subject:

Re: [rt-pmc] Bundle major versions and project major release





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


Back to the top