Re: Addition of Mach-O 64 Binary Parser to 6.0.2
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
by John Cortell-4
::
Rate this Message:
Just curious, since Markus' suggestion to add the new parser without
exposing new API makes the question moot...
From what I can tell, you can specify a maintenance version (x.y.z) in the version boundaries of a dependency. So why would a minor version bump be required in the supplier? John At 11:41 AM 11/3/2009, Christian W. Damus wrote: The problem with adding new API on the maintenance stream is that any client bundle that wants to use this new API needs a new minor version (x.y) of the bundle that supplies the API, in order to sensibly express a new lower bound in its dependency range. However, the supplier bundle can't actually raise its version to the next minor number because then (a) it will conflict with the minor version increment of the next release and (b) it will no longer look like a service release, so user installs performing service updates won't get anything. _______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
|
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
by Christian W. Damus-3
::
Rate this Message:
Hi, John,
The cheeky answer would be "because them's the rules that Eclipse projects adhere to." :-) http://wiki.eclipse.org/Version_Numbering#When_to_change_the_minor_segment A more practical answer is simply that it's not what clients expect. They generally never use the service increment in lower bounds because service releases only have bug fixes and not API changes. Service updates are "optional" in that sense; it doesn't make sense for a bundle to require a specific maintenance version because there wouldn't be any new API to use (that is the "expectation.") Maybe that's a chicken-and-egg argument? ;-) cW On Tue, 2009-11-03 at 13:29 -0600, John Cortell wrote: Just curious, since Markus' suggestion to add the new parser without exposing new API makes the question moot...
_______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
|
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
by John Cortell-4
::
Rate this Message:
Fair enough. So the "restriction" is really just rooted in
convention and expectations. And that's fair enough. I guess I'm just
trying to validate my understanding that there's no hard technical hurdle
preventing a supplier bundle from adding API and a client from using it.
The new API doesn't break clients, and it doesn't require clients to bump
their dependency version bounds except for the few (if any) that would
use the API in that release.
John At 01:47 PM 11/3/2009, Christian W. Damus wrote: Hi, John, _______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
|
|
|
Re: Addition of Mach-O 64 Binary Parser to 6.0.2
by Christian W. Damus-3
::
Rate this Message:
Hi, John,
Yes, I think I have the same understanding as you. There is nothing that I know of that makes it infeasible for a willing client to require a service-level version of another plug-in with the knowledge that it provides new non-breaking API. This is almost certainly a perfectly harmless case in which that would work. I think that a few years of being responsible for the release process of a few modeling project components with many dependents has bludgeoned the "rules" into my brain to the point where it no longer perceives the colour grey. :-D cW On Tue, 2009-11-03 at 14:02 -0600, John Cortell wrote: Fair enough. So the "restriction" is really just rooted in convention and expectations. And that's fair enough. I guess I'm just trying to validate my understanding that there's no hard technical hurdle preventing a supplier bundle from adding API and a client from using it. The new API doesn't break clients, and it doesn't require clients to bump their dependency version bounds except for the few (if any) that would use the API in that release. --------8<--------
_______________________________________________ cdt-dev mailing list cdt-dev@... https://dev.eclipse.org/mailman/listinfo/cdt-dev |
| Free embeddable forum powered by Nabble | Forum Help |
