How do we define 'major' release for the simultaneous release? I understand our semantic version scheme for bundles, but how does that move up the stack to the train? Does the train itself increment it's major version if one of the bundles breaks API,
or increments its major version?
We don’t version the simrel now other than a goofy name ;). I imagine we would keep with that. And with that, the date number probably make more sense. 16.06, 16.09, …
From Luna SR0 - SR2 there were 62 Installable Units that had a major version changes. I don't know if these IUs represent bundles that contain API, but if they do, then wouldn't that mean that SR2 was a Major Release?
Sorry, looking at your list, I don’t see any one with a major version change, e.g. 5.0.0. Lots of minor version changes, 8.7.0, but those are allowed on an SR at the moment. Ideally, only third digit increments are allowed on a SR.
From Luna SR0 - SR2 there were 1100 Installable Units that had minor version changes, presumably many of those had new API.
Doug's right, calling our Fall and Winter releases 'SRs' is lying, especially when we have strict rules about API and Eclipse has been the gold standard for API compatibility. We were doing semantic versioning before the term semantic versioning existed.
So there is really 3 parts to this whole discussion:
- Fix the name / message around our Fall and Winter releases.
- Improve the frequency at which Eclipse projects can get their bits into users hands
- Formalize what we expect regarding API and the Simultaneous Release Train
I've attached the results of my analysis (major & minor increment from SR0 to SR1). I wrote a small script to pull this data and did a few sanity checks. If you see anything wrong, please let me know. A really interesting one is the bundle org.eclipse.rcp
when from 4.3.100. to 4.4.2 between SR0 and SR2.
Cheers,
Ian
|