James Falkner 10年 前 "The build should be able to detect whether the change requires a version update." - how would that happen? Clearly, if a method signature changes, that's probably cause to rev the interface version, but what if the change is in some sense compatible - e.g. you added a new, but optional parameter, with a sensible default? Or, what if the return type doesn't change, but the logic inside a method changes so that output is now different? At what point is it up to a developer vs. an automated process? Also, what about the notion of interface stability? Is it possible in the OSGi world to declare an unstable interface, that will probably change, but developers are free to bind to it (with the understanding that it might change/disappear)? 投票するためにはログインが必要です。 次として送信する: キャンセル Ray Augé James Falkner 10年 前 Obviously logical changes are hard to detect. But you usually do so in fixing a bug or other type of flaw which should still require the package to indicate a change using a micro version update.Meanwhile, those are the least likely to break other peoples code (although when they do they are the hardest to resolve).By far the largest "manageable" set are those changes which directly alter the API: adds, removes, changes. These we can teach the developer how to deal with by using tooling, which is what I'm trying to accomplish. 投票するためにはログインが必要です。 次として送信する: キャンセル
Ray Augé James Falkner 10年 前 Obviously logical changes are hard to detect. But you usually do so in fixing a bug or other type of flaw which should still require the package to indicate a change using a micro version update.Meanwhile, those are the least likely to break other peoples code (although when they do they are the hardest to resolve).By far the largest "manageable" set are those changes which directly alter the API: adds, removes, changes. These we can teach the developer how to deal with by using tooling, which is what I'm trying to accomplish. 投票するためにはログインが必要です。 次として送信する: キャンセル