> ok, then what could be done is only a check afterwards that the version > chosen > by the user is consistent with measures on code evolutions So we are back on version policy I think. Only check and stop the release based on the policy.
> another idea: perhaps we should have the API propose multiple versions > instead > of only one. This would help people understand that the API is only about > guessing a natural "next" version, but there are multiple good answers and > the > right one is really depending on what the user wants to do at current time > (going to next major version or minor version?) This could/should be a part of the version policy implementation. The release plugin itself only reacts on the result of the version policy. The package based approach of OSGi (bundle-maven-plugin) will be also interesting in use with Jigsaw (Java 9 modules). OSGi makes a bit easier with the separation/declaration of public and private packages. The first idea for POJ (Plain Old Java) could be to configure the more public part as API (like the bundle-maven-plugin also does) or use the whole artifact as API instead. This approach is as strict but clean as possible. But maybe this behaviour is too strict, so it could be a part of a 'strict server' version policy implementation. mit freundlichen Grüßen Uwe Barthel -- [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
