Do you think the proposed 2.3.1 that depends on uimaj 2.9.0 could instead depend on uimaj 2.9.0 or 2.10.0?
-M On 5/17/2017 3:15 PM, Richard Eckart de Castilho wrote: > 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
