Hi,
I would call it clean up of really ugly old code :-) I could introduce internal packages, but right now it is the other way around. The main API is defined by the configuration parameters of the analysis engine, thus the semver is configured to check the packages that concern the analysis engines and the descriptors. What broke the enforcer rule was the removal of public stuff in the analysis engine. I have plan to improve the usage of Ruta as a java library. Then, I should really be more careful about these changes. Best, Peter Am 26.07.2016 um 15:33 schrieb Marshall Schor: > Sounds OK from a risk/benefits point of view. > > A reminder - in UIMA we use "public" for 2 purposes: > > a) identifying a user-facing API that we want to maintain and keep stable > over releases > > b) making an internal-use method/field accessible from a different package > > > For things of class (b), we put them in a package with the word "impl" or > "internal", and then exclude things in those packages from semver. > > > I don't know if this applies to your current refactoring - if not, please > ignore > this suggestion :-). Otherwise, you might take this "turning off of semver" > to > refactor (b)'s that are not already in "impl" or "internal" packages. > > > Cheers. -Marshall > > On 7/26/2016 4:47 AM, Peter Klügl wrote: >> Hi, >> >> the latest changes break backwards compatibility, which would cause the >> next release to be 3.0.0. >> >> The reasons for the (theoretical) incompatibility are removed public >> methods due to refactoring (UIMA-5027) and the removal of a complete >> configuration parameter (UIMA-5029) (I know nobody that ever used it, >> not even me) >> >> Nevertheless, I plan the next release to be 2.5.0 with some special >> notes (semver enforcer deactivated). UIMA Ruta 3.0.0 is reserved for the >> uimaj-core 3.0.0 release. >> >> Best, >> >> Peter >> >>
