Sounds good to me. /Anders (mobile)
Den fre 8 mars 2024 11:19Tamás Cservenák <ta...@cservenak.net> skrev: > 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 > >> > >> >
