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

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I would go further and suggest three
part version numbers aren't even really needed as your project release
marketing number. You could just call your releases "Helios",
"Helios SR1", etc, or even something like "June 2009".
I think for a project like ECF in particular, where there are many different
unrelated components at different levels of maturity, giving a single "number"
to describe the release doesn't add much value. We've seen this transition
from three part numbers to more opaque release identifiers in other places,
such as Java itself dropping 1.x.y in favour of "one part" version
numbers (Java 6, Java 7, etc). Dropping the second and third digit takes
away the perception that there is a strong semantic value to the number
change, giving you the freedom to just increment every year. In this vein,
maybe you could just do "ECF 4", "ECF 5", etc.

If you do stick with a three part release
number, there are several of examples of projects shipping "minor"
releases that contain bundles with major version increases. For example
the Eclipse Platform shipped version 3.5, containing org.eclipse.ecf version
3.0, but Eclipse Platform 3.4 contained org.eclipse.ecf version 2.0. Another
one that comes to mind is the plug-in org.eclipse.ui.carbon, which is now
at version 4.0.0 in Eclipse Platform 3.5.

John

Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: rt-pmc-bounces@xxxxxxxxxxx

06/24/2009 11: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

Scott
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