So, can we agree on following (maybe even vote if needed)? I. Core Plugin Versioning Maven3 plugins carry 3.x as the major version number, and Maven4 plugins will carry 4.x major versions?
II. Consequence: How to interpret Core plugin versions See above. In short: the first element is "maven API level", rest could be "shifted left" and interpreted like that. III. Consequence: How to express Core plugin "breaking change"? Ideally, we should NOT have them. But, in case we must: - use minor bump and .0 patch to clearly show this is a "bigger" change (hence, 3.1.0 -> 3.2.0 should be interpreted by users like "I need to sift thru release notes before just blindly update") - clearly document the breakage in release notes, announce and site T On Thu, Mar 7, 2024 at 9:23 AM Tamás Cservenák <ta...@cservenak.net> wrote: > Michael, > > I am unsure why it would not work? As I explained in my initial email, > Maven2 plugins were 2.x, Maven3 plugins were 3.x, so why could not Maven4 > be 4.x? > I think that "maven plugin" is quite well defined (is not "just a jar"). > While I would expect your "bump the major version" for some library, in > maven land we can lay down our own rules. > This is not about history, but actually the opposite: how can the user > decide should it (or can it) jump from version X to X+1 (given the java, > maven he uses in build). > After all, if breakage is documented, users can adopt the plugin required > changes. > > I'd just like to keep it simple, and unchanged for now: it worked before > just fine. > > T > > On Thu, Mar 7, 2024 at 8:40 AM Michael Osipov <micha...@apache.org> wrote: > >> This is a general problem and cannot be solved. As soon as you need to >> break the plugin compat you need to bump the major version. That >> breakage does not need to be related to Maven at all. >> Upshot: No matter what you do, you will do it wrong. I would rely on >> MPLUGIN foo to manage he compat history. >> >> M >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >>
