Hello, If you include new functionality this means that according to semver you increase the second digit, which means conservative users will do this upgrade step not so easy anymore (and therefore miss all future fixes).
I would rather include enhancements anyway but divert from strict semver: The most visible change would be that the minimum prerequisites for a plugin needs to observe the last digit (like it is today). So the meanings of the digits are more risk than compatibility oriented. Applying stricter semver would require to not ship enhancements until a new functional release is cut (and then deciding if older functional releases still get bugfixes or not). Bernd BTW: I think this is totally Independent of the topic if running Integration builds with automatic promotions. > Am 19.02.2014 um 15:36 schrieb Paul Benedict <pbened...@apache.org>: > > I don't see any necessity to restrict patch releases to patches only -- as > long as any new functionality is a tiny enhancement and doesn't make > incompatibilities. Save medium/major structural changes for a new minor > version. > > > On Wed, Feb 19, 2014 at 7:37 AM, Benson Margulies > <bimargul...@gmail.com>wrote: > >> A bit of a recap: >> >> Let's say that our goal as a group was to be very responsive to user's >> bug reports. >> >> So, we'd want to make fixes and releases, 'promptly', for some >> definition of prompt. >> >> But no one will install those releases if they are not confident that >> they are, in fact, not going to have unexpected consequences. >> >> From a black-box standpoint, this can only be achieved with really >> strong integration tests. >> >> From a white-box standpoint, it seems to me that the Maven core has a >> tendency towards complex interactions in which a fix to problem (a) >> can have unexpected consequence (b). >> >> So, either way, Jason's views about testing seem spot-on. This leaves >> a question: should we be trying, still, to follow up a 3.2.0 with a >> pure bugfix 3.2.1, and holding off on structural repairs or new >> features until 3.3? One view is that we should try to get some of the >> tests improved and some of the structural repairs done before we make >> any attempt at semver/responsive releases. The other view is that >> should try to deliver on semver as best we can. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > -- > Cheers, > Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
