|Re: [cross-project-issues-dev] Juno M2 aggregation -- will it be the worst milestone ever?|
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.I don't know what to do. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=358558] I see two choices.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.
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
Back to the top