[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Addition of Mach-O 64 Binary Parser to 6.0.2
|
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,
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...
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.
If this really is new public API, then adding it in the maintenance
stream is certain to break some client workflows.
Cheers,
Christian
On Tue, 2009-11-03 at 11:27 -0600, John Cortell wrote:
I don't believe new API
is a problem, even for a maintenance release. I think stability is the
key. Any significant amount of code, API-related or not, that can
destabilize existing features is what we should avoid. I think a new
binary parser is a safe addition, as long as it hasn't mucked around much
with the underlying support code.
John
At 11:18 AM 11/3/2009, Andrew Gvozdev wrote:
Hi,
There is a contribution of Mach-O binary parser for Mac 64 bit. In CDT
6.1 it is being added as a new parser. I believe it would be valuable
addition to 6.0.X stream as well. Technically it introduces new API and
API changes for maintenance stream are not allowed but in this case I
would advocate to add it there.
Does anybody have an objection?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=270790
Andrew
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Christian W. Damus
Software Developer, IDE Team
QNX Software Systems
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Christian W. Damus
Software Developer, IDE Team
QNX Software Systems
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev