On 17.05.2017, at 20:41, Marshall Schor <[email protected]> wrote: > > 2 thoughts: > > 1) if your component doesn't require 2.10.0, but works with a range of > versions, > including 2.10.0, and > > - your component doesn't "include" core uima 2.10.0, then I think the version > numbering can be independent.
We could turn uimaFIT into a module of uimaj ;) Then we'd have only once release cycle. When uimaFIT was contributed, I was expecting that uimaFIT would be released more often than uimaj-core and I wanted to be able to have these faster release cycles. However, in reality, it turns out this was wishful thinking. At least at the moment, I rather manage to do less releases than Marshall. > 2) I suggest we be customer-focused, and try to have our version numbering > communicate useful information. So, to me, if we have a bug-fix release that > doesn't change customer-facing APIs except for perhaps adding new signatures > (which are very unlikely to collide with user methods) , I would treat this > as a > 3-rd digit increment, because that communicates best what an upgrader ought to > expect. I didn't feel comfortable upgrading the uimaj-core dependency to 2.10.0 and then only to increase the last digit. If felt that it would have been less customer-friendly to do that then to increase the middle number. Anyway, it was probably a bad idea anyway as Peter has pointed out. I'll do prepare a 2.3.1 that depends on uimaj-core 2.9.0. -- Richard
