Or maybe a 1 hundred bump: 3.12.1 -> 3.100.0 ? It may be more clear, as that's a number we don't usually reach...
Le ven. 8 mars 2024 à 17:20, Guillaume Nodet <gno...@apache.org> a écrit : > > I'm slightly hesitant about that. > It seems to me plugins have mostly been compatible, so we very rarely > used a major version switch, but we do have plugins in 3.12.1 for > example, which would be translated to 3.0.12.1. Not even sure how the > 4th digit is supported... > I wonder if an alternative proposal would be to do a 10 unit big jump > in the minor version to represent a breaking change, so from 3.12.1 to > 3.23.0.... > > Guillaume > > Le ven. 8 mars 2024 à 11:19, Tamás Cservenák <ta...@cservenak.net> a écrit : > > > > 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 > > >> > > >> > > > > -- > ------------------------ > Guillaume Nodet -- ------------------------ Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
