Re: [cross-project-issues-dev] Juno M2 aggregation -- will it be the wor

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi
> I think I have overinterpreted the versioning rules. We only a need a 
> major increment for UML-related plugins and almost all features. This 
> should be friendly downstream where consumers just reference by 
> feature name and mostly use non-UML plugins; consumers will just need 
> to get their platform, EMF, UML repos right.
>
> This seems to align with advice in 
> http://wiki.eclipse.org/Version_Numbering#Require_features which 
> points out that feature versions are brittle. It seems we will have 
> over 90% of the project at 3.2 but a small part at 4.0 and so almost 
> all features at 4.0.
I don't know what to do. 
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=358558] I see two choices.

a) good today: 90% of the project stays at 3.2, 10% increments to 4.0; 
relatively easy for downstream releng.
bad tomorrow: users must correctly use [3.2,4.0) or [4.x,5.0) bounds and 
know that 3.2 material, which may be all that they use, is called 4.0 
and found in 4.0 facilities.

b) irritating today and tomorrow: 100% of the project increments to 4.0; 
downstream projects must change all their explicit version bounds. Users 
must change all their explicit version bounds.

Given the timescales and that b) > a) we will proceed with a) ASAP 
(hudson is giving strange errors at present on 
https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.2-master/447/).

If appropriate we can proceed with b) for M2 or M3.

    Regards

        Ed Willink