You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Tamás Cservenák <ta...@cservenak.net> on 2024/03/06 13:58:01 UTC
[DISCUSS] Maven Core Plugins versioning
Howdy,
We have several topics that need to be discussed.
I. Core Plugin Versioning
History: When Maven2 was born, and started using plugins "as we know them
today" (Maven 1 was a very different beast), the Core Plugin versions were
started as 2.0 on purpose. Just check the Maven Central for historical
versions, some examples:
* clean
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
* compiler
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
* jar
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
* surefire
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
* dependency
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
beginning. Later on, when Maven3 came to existence, it was able to use
Maven2 plugins, the plugins were slowly migrated to become "Maven 3
plugins" (Maven2 could not use them anymore). This was denoted by the "3.x"
major plugin version jump.
So far, we have no 4.x plugin release of anything (M releases do not
count). But my question is the following:
How should we distinguish similar changes for Maven4?
Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
will NOT be able to use anymore (will be incompatible). Similarly as
before, Maven4 CAN run the "Maven 3" plugins, and will retain this
capability for some time. But other ways it does not work, nor never worked
(Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
Maven3 plugin).
For me, the logical answer to this question is the use of major version
4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin
version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
plugin" (Maven2 incompatible).
As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
confuse the hell out of our users. At least that is what I think.
II. Consequence: How to interpret Core plugin versions
As can be seen above, so far the major version of the plugin was kinda
showing "which Maven API level" is the plugin.
So, it begs the question: HOW to interpret the Maven Core Plugin version?
My interpretation was always: "shift it once left", meaning: Core plugin
version "3.2.1" MEANS:
- Maven API version: 3
- Core Plugin version 2.1(.0)
III. Consequence: How to express Core plugin "breaking change"?
Today, everyone expects a "major version jump" to express breaking changes.
BUT, as explained above, that would be totally misleading here, and would
break the "customary law" that Major expresses Maven lineage.
Ideas and opinions welcome.
T
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Konrad Windszus <kw...@apache.org>.
This is slightly differently described on https://maven.apache.org/plugins/
Core plugins Plugins corresponding to default core phases (ie. clean, compile). They may have multiple goals as well.
But I think the intention is clear: This should apply to all plugins maintained by the Apache Maven Project (not only core plugin according to the definition from above).
Konrad
> On 6. Mar 2024, at 15:12, Tamás Cservenák <ta...@cservenak.net> wrote:
>
> Gary,
>
> maven "core plugins" are these
> https://maven.apache.org/plugins/
>
> In short, Maven plugins that are maintained by this project at ASF.
>
> While there is a quite overlap with mojohaus etc, they are NOT core plugins
>
> T
>
> On Wed, Mar 6, 2024 at 3:09 PM Gary Gregory <ga...@gmail.com> wrote:
>
>> One issue from a non-Maven dev (me) is that I have no idea what is a
>> Maven "core" plugin vs. not. I would make that obvious for users, and
>> no, the "maven-" prefix does not make it obvious:
>>
>> maven-clean-plugin -> maven-core-clean-plugin or maven4-core-clean-plugin
>>
>> I'm also not sure the "plugin" suffix is needed:
>>
>> maven-clean-plugin -> maven-core-clean or maven4-core-clean
>>
>> My preference is "maven4-core-clean"
>>
>> Gary
>>
>> On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák <ta...@cservenak.net>
>> wrote:
>>>
>>> Howdy,
>>>
>>> We have several topics that need to be discussed.
>>>
>>> I. Core Plugin Versioning
>>>
>>> History: When Maven2 was born, and started using plugins "as we know them
>>> today" (Maven 1 was a very different beast), the Core Plugin versions
>> were
>>> started as 2.0 on purpose. Just check the Maven Central for historical
>>> versions, some examples:
>>> * clean
>>>
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
>>> * compiler
>>>
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
>>> * jar
>>>
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
>>> * surefire
>>>
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
>>> * dependency
>>>
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
>>>
>>> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
>>> beginning. Later on, when Maven3 came to existence, it was able to use
>>> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
>>> plugins" (Maven2 could not use them anymore). This was denoted by the
>> "3.x"
>>> major plugin version jump.
>>>
>>> So far, we have no 4.x plugin release of anything (M releases do not
>>> count). But my question is the following:
>>>
>>> How should we distinguish similar changes for Maven4?
>>>
>>> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
>>> will NOT be able to use anymore (will be incompatible). Similarly as
>>> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
>>> capability for some time. But other ways it does not work, nor never
>> worked
>>> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
>>> Maven3 plugin).
>>>
>>> For me, the logical answer to this question is the use of major version
>>> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a
>> plugin
>>> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
>>> plugin" (Maven2 incompatible).
>>>
>>> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
>>> confuse the hell out of our users. At least that is what I think.
>>>
>>> II. Consequence: How to interpret Core plugin versions
>>>
>>> As can be seen above, so far the major version of the plugin was kinda
>>> showing "which Maven API level" is the plugin.
>>>
>>> So, it begs the question: HOW to interpret the Maven Core Plugin version?
>>>
>>> My interpretation was always: "shift it once left", meaning: Core plugin
>>> version "3.2.1" MEANS:
>>> - Maven API version: 3
>>> - Core Plugin version 2.1(.0)
>>>
>>> III. Consequence: How to express Core plugin "breaking change"?
>>>
>>> Today, everyone expects a "major version jump" to express breaking
>> changes.
>>> BUT, as explained above, that would be totally misleading here, and would
>>> break the "customary law" that Major expresses Maven lineage.
>>>
>>> Ideas and opinions welcome.
>>>
>>> T
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
Gary,
maven "core plugins" are these
https://maven.apache.org/plugins/
In short, Maven plugins that are maintained by this project at ASF.
While there is a quite overlap with mojohaus etc, they are NOT core plugins
T
On Wed, Mar 6, 2024 at 3:09 PM Gary Gregory <ga...@gmail.com> wrote:
> One issue from a non-Maven dev (me) is that I have no idea what is a
> Maven "core" plugin vs. not. I would make that obvious for users, and
> no, the "maven-" prefix does not make it obvious:
>
> maven-clean-plugin -> maven-core-clean-plugin or maven4-core-clean-plugin
>
> I'm also not sure the "plugin" suffix is needed:
>
> maven-clean-plugin -> maven-core-clean or maven4-core-clean
>
> My preference is "maven4-core-clean"
>
> Gary
>
> On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák <ta...@cservenak.net>
> wrote:
> >
> > Howdy,
> >
> > We have several topics that need to be discussed.
> >
> > I. Core Plugin Versioning
> >
> > History: When Maven2 was born, and started using plugins "as we know them
> > today" (Maven 1 was a very different beast), the Core Plugin versions
> were
> > started as 2.0 on purpose. Just check the Maven Central for historical
> > versions, some examples:
> > * clean
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> > * compiler
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> > * jar
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> > * surefire
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> > * dependency
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
> >
> > So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> > beginning. Later on, when Maven3 came to existence, it was able to use
> > Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> > plugins" (Maven2 could not use them anymore). This was denoted by the
> "3.x"
> > major plugin version jump.
> >
> > So far, we have no 4.x plugin release of anything (M releases do not
> > count). But my question is the following:
> >
> > How should we distinguish similar changes for Maven4?
> >
> > Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> > will NOT be able to use anymore (will be incompatible). Similarly as
> > before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> > capability for some time. But other ways it does not work, nor never
> worked
> > (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> > Maven3 plugin).
> >
> > For me, the logical answer to this question is the use of major version
> > 4.x. So just like it happened with Maven 2 to Maven 3 transition, a
> plugin
> > version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> > plugin" (Maven2 incompatible).
> >
> > As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> > confuse the hell out of our users. At least that is what I think.
> >
> > II. Consequence: How to interpret Core plugin versions
> >
> > As can be seen above, so far the major version of the plugin was kinda
> > showing "which Maven API level" is the plugin.
> >
> > So, it begs the question: HOW to interpret the Maven Core Plugin version?
> >
> > My interpretation was always: "shift it once left", meaning: Core plugin
> > version "3.2.1" MEANS:
> > - Maven API version: 3
> > - Core Plugin version 2.1(.0)
> >
> > III. Consequence: How to express Core plugin "breaking change"?
> >
> > Today, everyone expects a "major version jump" to express breaking
> changes.
> > BUT, as explained above, that would be totally misleading here, and would
> > break the "customary law" that Major expresses Maven lineage.
> >
> > Ideas and opinions welcome.
> >
> > T
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Ok, I'd just use semver prefixing the plugin with the intended maven
version (unspecified what happens if not aligned).
It is always how it got perceived and I think it is good enough.
About the naming I agree the plugin suffix is quite pointless as the maven
prefix since we have the groupId, adding code would be dropping an useless
part to add yet another useless part, core is just our way to say
org.apache.maven.plugins and it is obvious enough for any maven user that a
groupId is owned by a project IMHO so either status quo on this one or drop
prefix/suffix would be my 2 cts.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 6 mars 2024 à 15:16, Tamás Cservenák <ta...@cservenak.net> a écrit :
> +1 to that definition
>
> On Wed, Mar 6, 2024 at 3:14 PM Konrad Windszus <kw...@apache.org> wrote:
>
> > Maven Core plugins are listed in https://maven.apache.org/plugins/.
> > But I would say that this versioning policy applies to all plugins in
> > groupId org.apache.maven.plugins…..
> >
> > Konrad
> >
> > > On 6. Mar 2024, at 15:06, Gary Gregory <ga...@gmail.com> wrote:
> > >
> > > One issue from a non-Maven dev (me) is that I have no idea what is a
> > > Maven "core" plugin vs. not. I would make that obvious for users, and
> > > no, the "maven-" prefix does not make it obvious:
> > >
> > > maven-clean-plugin -> maven-core-clean-plugin or
> maven4-core-clean-plugin
> > >
> > > I'm also not sure the "plugin" suffix is needed:
> > >
> > > maven-clean-plugin -> maven-core-clean or maven4-core-clean
> > >
> > > My preference is "maven4-core-clean"
> > >
> > > Gary
> > >
> > > On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák <ta...@cservenak.net>
> > wrote:
> > >>
> > >> Howdy,
> > >>
> > >> We have several topics that need to be discussed.
> > >>
> > >> I. Core Plugin Versioning
> > >>
> > >> History: When Maven2 was born, and started using plugins "as we know
> > them
> > >> today" (Maven 1 was a very different beast), the Core Plugin versions
> > were
> > >> started as 2.0 on purpose. Just check the Maven Central for historical
> > >> versions, some examples:
> > >> * clean
> > >>
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> > >> * compiler
> > >>
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> > >> * jar
> > >>
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> > >> * surefire
> > >>
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> > >> * dependency
> > >>
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
> > >>
> > >> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> > >> beginning. Later on, when Maven3 came to existence, it was able to use
> > >> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> > >> plugins" (Maven2 could not use them anymore). This was denoted by the
> > "3.x"
> > >> major plugin version jump.
> > >>
> > >> So far, we have no 4.x plugin release of anything (M releases do not
> > >> count). But my question is the following:
> > >>
> > >> How should we distinguish similar changes for Maven4?
> > >>
> > >> Explanation: when a plugin is migrated to Maven4 API, it will mean
> > Maven3
> > >> will NOT be able to use anymore (will be incompatible). Similarly as
> > >> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> > >> capability for some time. But other ways it does not work, nor never
> > worked
> > >> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never
> > ran
> > >> Maven3 plugin).
> > >>
> > >> For me, the logical answer to this question is the use of major
> version
> > >> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a
> > plugin
> > >> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> > >> plugin" (Maven2 incompatible).
> > >>
> > >> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> > >> confuse the hell out of our users. At least that is what I think.
> > >>
> > >> II. Consequence: How to interpret Core plugin versions
> > >>
> > >> As can be seen above, so far the major version of the plugin was kinda
> > >> showing "which Maven API level" is the plugin.
> > >>
> > >> So, it begs the question: HOW to interpret the Maven Core Plugin
> > version?
> > >>
> > >> My interpretation was always: "shift it once left", meaning: Core
> plugin
> > >> version "3.2.1" MEANS:
> > >> - Maven API version: 3
> > >> - Core Plugin version 2.1(.0)
> > >>
> > >> III. Consequence: How to express Core plugin "breaking change"?
> > >>
> > >> Today, everyone expects a "major version jump" to express breaking
> > changes.
> > >> BUT, as explained above, that would be totally misleading here, and
> > would
> > >> break the "customary law" that Major expresses Maven lineage.
> > >>
> > >> Ideas and opinions welcome.
> > >>
> > >> T
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> >
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
+1 to that definition
On Wed, Mar 6, 2024 at 3:14 PM Konrad Windszus <kw...@apache.org> wrote:
> Maven Core plugins are listed in https://maven.apache.org/plugins/.
> But I would say that this versioning policy applies to all plugins in
> groupId org.apache.maven.plugins…..
>
> Konrad
>
> > On 6. Mar 2024, at 15:06, Gary Gregory <ga...@gmail.com> wrote:
> >
> > One issue from a non-Maven dev (me) is that I have no idea what is a
> > Maven "core" plugin vs. not. I would make that obvious for users, and
> > no, the "maven-" prefix does not make it obvious:
> >
> > maven-clean-plugin -> maven-core-clean-plugin or maven4-core-clean-plugin
> >
> > I'm also not sure the "plugin" suffix is needed:
> >
> > maven-clean-plugin -> maven-core-clean or maven4-core-clean
> >
> > My preference is "maven4-core-clean"
> >
> > Gary
> >
> > On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák <ta...@cservenak.net>
> wrote:
> >>
> >> Howdy,
> >>
> >> We have several topics that need to be discussed.
> >>
> >> I. Core Plugin Versioning
> >>
> >> History: When Maven2 was born, and started using plugins "as we know
> them
> >> today" (Maven 1 was a very different beast), the Core Plugin versions
> were
> >> started as 2.0 on purpose. Just check the Maven Central for historical
> >> versions, some examples:
> >> * clean
> >>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> >> * compiler
> >>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> >> * jar
> >>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> >> * surefire
> >>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> >> * dependency
> >>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
> >>
> >> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> >> beginning. Later on, when Maven3 came to existence, it was able to use
> >> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> >> plugins" (Maven2 could not use them anymore). This was denoted by the
> "3.x"
> >> major plugin version jump.
> >>
> >> So far, we have no 4.x plugin release of anything (M releases do not
> >> count). But my question is the following:
> >>
> >> How should we distinguish similar changes for Maven4?
> >>
> >> Explanation: when a plugin is migrated to Maven4 API, it will mean
> Maven3
> >> will NOT be able to use anymore (will be incompatible). Similarly as
> >> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> >> capability for some time. But other ways it does not work, nor never
> worked
> >> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never
> ran
> >> Maven3 plugin).
> >>
> >> For me, the logical answer to this question is the use of major version
> >> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a
> plugin
> >> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> >> plugin" (Maven2 incompatible).
> >>
> >> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> >> confuse the hell out of our users. At least that is what I think.
> >>
> >> II. Consequence: How to interpret Core plugin versions
> >>
> >> As can be seen above, so far the major version of the plugin was kinda
> >> showing "which Maven API level" is the plugin.
> >>
> >> So, it begs the question: HOW to interpret the Maven Core Plugin
> version?
> >>
> >> My interpretation was always: "shift it once left", meaning: Core plugin
> >> version "3.2.1" MEANS:
> >> - Maven API version: 3
> >> - Core Plugin version 2.1(.0)
> >>
> >> III. Consequence: How to express Core plugin "breaking change"?
> >>
> >> Today, everyone expects a "major version jump" to express breaking
> changes.
> >> BUT, as explained above, that would be totally misleading here, and
> would
> >> break the "customary law" that Major expresses Maven lineage.
> >>
> >> Ideas and opinions welcome.
> >>
> >> T
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Konrad Windszus <kw...@apache.org>.
Maven Core plugins are listed in https://maven.apache.org/plugins/.
But I would say that this versioning policy applies to all plugins in groupId org.apache.maven.plugins…..
Konrad
> On 6. Mar 2024, at 15:06, Gary Gregory <ga...@gmail.com> wrote:
>
> One issue from a non-Maven dev (me) is that I have no idea what is a
> Maven "core" plugin vs. not. I would make that obvious for users, and
> no, the "maven-" prefix does not make it obvious:
>
> maven-clean-plugin -> maven-core-clean-plugin or maven4-core-clean-plugin
>
> I'm also not sure the "plugin" suffix is needed:
>
> maven-clean-plugin -> maven-core-clean or maven4-core-clean
>
> My preference is "maven4-core-clean"
>
> Gary
>
> On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák <ta...@cservenak.net> wrote:
>>
>> Howdy,
>>
>> We have several topics that need to be discussed.
>>
>> I. Core Plugin Versioning
>>
>> History: When Maven2 was born, and started using plugins "as we know them
>> today" (Maven 1 was a very different beast), the Core Plugin versions were
>> started as 2.0 on purpose. Just check the Maven Central for historical
>> versions, some examples:
>> * clean
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
>> * compiler
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
>> * jar
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
>> * surefire
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
>> * dependency
>> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
>>
>> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
>> beginning. Later on, when Maven3 came to existence, it was able to use
>> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
>> plugins" (Maven2 could not use them anymore). This was denoted by the "3.x"
>> major plugin version jump.
>>
>> So far, we have no 4.x plugin release of anything (M releases do not
>> count). But my question is the following:
>>
>> How should we distinguish similar changes for Maven4?
>>
>> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
>> will NOT be able to use anymore (will be incompatible). Similarly as
>> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
>> capability for some time. But other ways it does not work, nor never worked
>> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
>> Maven3 plugin).
>>
>> For me, the logical answer to this question is the use of major version
>> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin
>> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
>> plugin" (Maven2 incompatible).
>>
>> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
>> confuse the hell out of our users. At least that is what I think.
>>
>> II. Consequence: How to interpret Core plugin versions
>>
>> As can be seen above, so far the major version of the plugin was kinda
>> showing "which Maven API level" is the plugin.
>>
>> So, it begs the question: HOW to interpret the Maven Core Plugin version?
>>
>> My interpretation was always: "shift it once left", meaning: Core plugin
>> version "3.2.1" MEANS:
>> - Maven API version: 3
>> - Core Plugin version 2.1(.0)
>>
>> III. Consequence: How to express Core plugin "breaking change"?
>>
>> Today, everyone expects a "major version jump" to express breaking changes.
>> BUT, as explained above, that would be totally misleading here, and would
>> break the "customary law" that Major expresses Maven lineage.
>>
>> Ideas and opinions welcome.
>>
>> T
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Gary Gregory <ga...@gmail.com>.
One issue from a non-Maven dev (me) is that I have no idea what is a
Maven "core" plugin vs. not. I would make that obvious for users, and
no, the "maven-" prefix does not make it obvious:
maven-clean-plugin -> maven-core-clean-plugin or maven4-core-clean-plugin
I'm also not sure the "plugin" suffix is needed:
maven-clean-plugin -> maven-core-clean or maven4-core-clean
My preference is "maven4-core-clean"
Gary
On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák <ta...@cservenak.net> wrote:
>
> Howdy,
>
> We have several topics that need to be discussed.
>
> I. Core Plugin Versioning
>
> History: When Maven2 was born, and started using plugins "as we know them
> today" (Maven 1 was a very different beast), the Core Plugin versions were
> started as 2.0 on purpose. Just check the Maven Central for historical
> versions, some examples:
> * clean
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> * compiler
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> * jar
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> * surefire
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> * dependency
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
>
> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> beginning. Later on, when Maven3 came to existence, it was able to use
> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> plugins" (Maven2 could not use them anymore). This was denoted by the "3.x"
> major plugin version jump.
>
> So far, we have no 4.x plugin release of anything (M releases do not
> count). But my question is the following:
>
> How should we distinguish similar changes for Maven4?
>
> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> will NOT be able to use anymore (will be incompatible). Similarly as
> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> capability for some time. But other ways it does not work, nor never worked
> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> Maven3 plugin).
>
> For me, the logical answer to this question is the use of major version
> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin
> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> plugin" (Maven2 incompatible).
>
> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> confuse the hell out of our users. At least that is what I think.
>
> II. Consequence: How to interpret Core plugin versions
>
> As can be seen above, so far the major version of the plugin was kinda
> showing "which Maven API level" is the plugin.
>
> So, it begs the question: HOW to interpret the Maven Core Plugin version?
>
> My interpretation was always: "shift it once left", meaning: Core plugin
> version "3.2.1" MEANS:
> - Maven API version: 3
> - Core Plugin version 2.1(.0)
>
> III. Consequence: How to express Core plugin "breaking change"?
>
> Today, everyone expects a "major version jump" to express breaking changes.
> BUT, as explained above, that would be totally misleading here, and would
> break the "customary law" that Major expresses Maven lineage.
>
> Ideas and opinions welcome.
>
> T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Konrad Windszus <kw...@apache.org>.
Hi,
I agree with both I. and II.
Not sure I understand the need for III.
IMHO breaking changes for users should almost never happen (or if at all only after a long deprecation phase)
Maybe you can give an example you have in mind for III?
But to make it visible to users I would say such an extraordinary case would probably justify a change of the artifactId.
Konrad
> On 6. Mar 2024, at 14:58, Tamás Cservenák <ta...@cservenak.net> wrote:
>
> Howdy,
>
> We have several topics that need to be discussed.
>
> I. Core Plugin Versioning
>
> History: When Maven2 was born, and started using plugins "as we know them
> today" (Maven 1 was a very different beast), the Core Plugin versions were
> started as 2.0 on purpose. Just check the Maven Central for historical
> versions, some examples:
> * clean
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> * compiler
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> * jar
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> * surefire
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> * dependency
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
>
> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> beginning. Later on, when Maven3 came to existence, it was able to use
> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> plugins" (Maven2 could not use them anymore). This was denoted by the "3.x"
> major plugin version jump.
>
> So far, we have no 4.x plugin release of anything (M releases do not
> count). But my question is the following:
>
> How should we distinguish similar changes for Maven4?
>
> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> will NOT be able to use anymore (will be incompatible). Similarly as
> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> capability for some time. But other ways it does not work, nor never worked
> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> Maven3 plugin).
>
> For me, the logical answer to this question is the use of major version
> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin
> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> plugin" (Maven2 incompatible).
>
> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> confuse the hell out of our users. At least that is what I think.
>
> II. Consequence: How to interpret Core plugin versions
>
> As can be seen above, so far the major version of the plugin was kinda
> showing "which Maven API level" is the plugin.
>
> So, it begs the question: HOW to interpret the Maven Core Plugin version?
>
> My interpretation was always: "shift it once left", meaning: Core plugin
> version "3.2.1" MEANS:
> - Maven API version: 3
> - Core Plugin version 2.1(.0)
>
> III. Consequence: How to express Core plugin "breaking change"?
>
> Today, everyone expects a "major version jump" to express breaking changes.
> BUT, as explained above, that would be totally misleading here, and would
> break the "customary law" that Major expresses Maven lineage.
>
> Ideas and opinions welcome.
>
> T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Matthias bünger <ru...@web.de.INVALID>.
Hey all,
my thoughts on these questions are quite that we should keep it as simple as it is:
I see value in keeping the versioning and its semantics with the Maven API at the first slot. This makes it an easy to see indicator and keeps the experience /knowledge of long time Maven users. About the question for breaking changes: The minor version (2nd slot) can be the indicator for major changes (breaking or not) - don‘t forget the documentation aside the version number. We can easily describe the version semantic in general and list/highlight (breaking) changes in the release notes or maybe add an addional indicator (eg a „breaking“ flag in the versions overview). Also remember yourself: With Maven 3.9.0 the required Java version to run Maven was lifted to 8 - so breaking change without increasing the first number - indicated by another color (and the different number) in the java coloumn on the release page.
At my work we do similar versioning semantic like the Maven one: our XSD where the first number is equal to version of the system of our major internal service provider (who handles in- and outcoming files).
Greetings
Matthias
Von meinem iPhone gesendet
> Am 06.03.2024 um 14:59 schrieb Tamás Cservenák <ta...@cservenak.net>:
>
> Howdy,
>
> We have several topics that need to be discussed.
>
> I. Core Plugin Versioning
>
> History: When Maven2 was born, and started using plugins "as we know them
> today" (Maven 1 was a very different beast), the Core Plugin versions were
> started as 2.0 on purpose. Just check the Maven Central for historical
> versions, some examples:
> * clean
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> * compiler
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> * jar
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> * surefire
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> * dependency
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
>
> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> beginning. Later on, when Maven3 came to existence, it was able to use
> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> plugins" (Maven2 could not use them anymore). This was denoted by the "3.x"
> major plugin version jump.
>
> So far, we have no 4.x plugin release of anything (M releases do not
> count). But my question is the following:
>
> How should we distinguish similar changes for Maven4?
>
> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> will NOT be able to use anymore (will be incompatible). Similarly as
> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> capability for some time. But other ways it does not work, nor never worked
> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> Maven3 plugin).
>
> For me, the logical answer to this question is the use of major version
> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin
> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> plugin" (Maven2 incompatible).
>
> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> confuse the hell out of our users. At least that is what I think.
>
> II. Consequence: How to interpret Core plugin versions
>
> As can be seen above, so far the major version of the plugin was kinda
> showing "which Maven API level" is the plugin.
>
> So, it begs the question: HOW to interpret the Maven Core Plugin version?
>
> My interpretation was always: "shift it once left", meaning: Core plugin
> version "3.2.1" MEANS:
> - Maven API version: 3
> - Core Plugin version 2.1(.0)
>
> III. Consequence: How to express Core plugin "breaking change"?
>
> Today, everyone expects a "major version jump" to express breaking changes.
> BUT, as explained above, that would be totally misleading here, and would
> break the "customary law" that Major expresses Maven lineage.
>
> Ideas and opinions welcome.
>
> T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
Romain,
we have multiple ONGOING issues:
- site plugin IMHO must not be 4.x (as it is still a Maven3 plugin, it does
not use Maven4 API). OTOH, it _is a breaking change_, so users need to
adjust their builds once upgraded
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-site-plugin/
- same stands for incoming maven-gpg-plugin (breaking change that will
break their builds if only thing they do is "bump version")
- incoming Maven4 plugins (many of them are already migrated, sitting on
mvn4 branches)
- incoming new compiler plugin(s), etc
To start/do any of these, we MUST align on these IMHO.
T
On Wed, Mar 6, 2024 at 3:05 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi Tamas,
>
> Not sure I really got the issue, is it to do a breaking change without a
> maven-core bump?
>
> I tend to agree with you, ie the versioning is
> $mavenCoreMajor.$pluginMajor.$pluginMinor and no patch digit and guess it
> works good enough even for users, no?
>
> Best,
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 6 mars 2024 à 14:59, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > Howdy,
> >
> > We have several topics that need to be discussed.
> >
> > I. Core Plugin Versioning
> >
> > History: When Maven2 was born, and started using plugins "as we know them
> > today" (Maven 1 was a very different beast), the Core Plugin versions
> were
> > started as 2.0 on purpose. Just check the Maven Central for historical
> > versions, some examples:
> > * clean
> >
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> > * compiler
> >
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> > * jar
> >
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> > * surefire
> >
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> > * dependency
> >
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
> >
> > So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> > beginning. Later on, when Maven3 came to existence, it was able to use
> > Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> > plugins" (Maven2 could not use them anymore). This was denoted by the
> "3.x"
> > major plugin version jump.
> >
> > So far, we have no 4.x plugin release of anything (M releases do not
> > count). But my question is the following:
> >
> > How should we distinguish similar changes for Maven4?
> >
> > Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> > will NOT be able to use anymore (will be incompatible). Similarly as
> > before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> > capability for some time. But other ways it does not work, nor never
> worked
> > (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> > Maven3 plugin).
> >
> > For me, the logical answer to this question is the use of major version
> > 4.x. So just like it happened with Maven 2 to Maven 3 transition, a
> plugin
> > version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> > plugin" (Maven2 incompatible).
> >
> > As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> > confuse the hell out of our users. At least that is what I think.
> >
> > II. Consequence: How to interpret Core plugin versions
> >
> > As can be seen above, so far the major version of the plugin was kinda
> > showing "which Maven API level" is the plugin.
> >
> > So, it begs the question: HOW to interpret the Maven Core Plugin version?
> >
> > My interpretation was always: "shift it once left", meaning: Core plugin
> > version "3.2.1" MEANS:
> > - Maven API version: 3
> > - Core Plugin version 2.1(.0)
> >
> > III. Consequence: How to express Core plugin "breaking change"?
> >
> > Today, everyone expects a "major version jump" to express breaking
> changes.
> > BUT, as explained above, that would be totally misleading here, and would
> > break the "customary law" that Major expresses Maven lineage.
> >
> > Ideas and opinions welcome.
> >
> > T
> >
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Tamas,
Not sure I really got the issue, is it to do a breaking change without a
maven-core bump?
I tend to agree with you, ie the versioning is
$mavenCoreMajor.$pluginMajor.$pluginMinor and no patch digit and guess it
works good enough even for users, no?
Best,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 6 mars 2024 à 14:59, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Howdy,
>
> We have several topics that need to be discussed.
>
> I. Core Plugin Versioning
>
> History: When Maven2 was born, and started using plugins "as we know them
> today" (Maven 1 was a very different beast), the Core Plugin versions were
> started as 2.0 on purpose. Just check the Maven Central for historical
> versions, some examples:
> * clean
>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> * compiler
>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> * jar
>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> * surefire
>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> * dependency
>
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
>
> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> beginning. Later on, when Maven3 came to existence, it was able to use
> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> plugins" (Maven2 could not use them anymore). This was denoted by the "3.x"
> major plugin version jump.
>
> So far, we have no 4.x plugin release of anything (M releases do not
> count). But my question is the following:
>
> How should we distinguish similar changes for Maven4?
>
> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> will NOT be able to use anymore (will be incompatible). Similarly as
> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> capability for some time. But other ways it does not work, nor never worked
> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> Maven3 plugin).
>
> For me, the logical answer to this question is the use of major version
> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin
> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> plugin" (Maven2 incompatible).
>
> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> confuse the hell out of our users. At least that is what I think.
>
> II. Consequence: How to interpret Core plugin versions
>
> As can be seen above, so far the major version of the plugin was kinda
> showing "which Maven API level" is the plugin.
>
> So, it begs the question: HOW to interpret the Maven Core Plugin version?
>
> My interpretation was always: "shift it once left", meaning: Core plugin
> version "3.2.1" MEANS:
> - Maven API version: 3
> - Core Plugin version 2.1(.0)
>
> III. Consequence: How to express Core plugin "breaking change"?
>
> Today, everyone expects a "major version jump" to express breaking changes.
> BUT, as explained above, that would be totally misleading here, and would
> break the "customary law" that Major expresses Maven lineage.
>
> Ideas and opinions welcome.
>
> T
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Hervé,
Think we can try to just move forward the v4 effort and if there are enough
requests on v3 we would maintain it as a best effort but as it had been
mentionned there is no more any real reason to do both as soon as maven v4
is officially out - ie final - IMHO.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 12 mars 2024 à 08:49, Herve Boutemy <hb...@apache.org> a écrit :
> using 4.x scheme looks simple and working: ok there is an exception with
> site, as there are always exceptions
>
> what is important is system prerequisites history: remember for JDK
> requirement? same for Maven version requirement
> just need to finish work on MPLUGIN-511 and we'll get the documentation
> automated
>
> I hope we also have good error messages at runtime both in Maven 3 and 4
>
> what makes me fear future headache is to decide if we maintain 2 branches
> (3.x and 4.x) in parallel of our ~50 plugins or if we just stop 3.x branch,
> or if we in general don't yet publish the 4.x branch unless there is a very
> good reason
> or... any other idea that permits reasonable maintenance effort for us and
> reasonable service to our users community
>
> Regards,
>
> Hervé
>
> On 2024/03/06 13:58:01 Tamás Cservenák wrote:
> > Howdy,
> >
> > We have several topics that need to be discussed.
> >
> > I. Core Plugin Versioning
> >
> > History: When Maven2 was born, and started using plugins "as we know them
> > today" (Maven 1 was a very different beast), the Core Plugin versions
> were
> > started as 2.0 on purpose. Just check the Maven Central for historical
> > versions, some examples:
> > * clean
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> > * compiler
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> > * jar
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> > * surefire
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> > * dependency
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
> >
> > So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> > beginning. Later on, when Maven3 came to existence, it was able to use
> > Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> > plugins" (Maven2 could not use them anymore). This was denoted by the
> "3.x"
> > major plugin version jump.
> >
> > So far, we have no 4.x plugin release of anything (M releases do not
> > count). But my question is the following:
> >
> > How should we distinguish similar changes for Maven4?
> >
> > Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> > will NOT be able to use anymore (will be incompatible). Similarly as
> > before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> > capability for some time. But other ways it does not work, nor never
> worked
> > (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> > Maven3 plugin).
> >
> > For me, the logical answer to this question is the use of major version
> > 4.x. So just like it happened with Maven 2 to Maven 3 transition, a
> plugin
> > version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> > plugin" (Maven2 incompatible).
> >
> > As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> > confuse the hell out of our users. At least that is what I think.
> >
> > II. Consequence: How to interpret Core plugin versions
> >
> > As can be seen above, so far the major version of the plugin was kinda
> > showing "which Maven API level" is the plugin.
> >
> > So, it begs the question: HOW to interpret the Maven Core Plugin version?
> >
> > My interpretation was always: "shift it once left", meaning: Core plugin
> > version "3.2.1" MEANS:
> > - Maven API version: 3
> > - Core Plugin version 2.1(.0)
> >
> > III. Consequence: How to express Core plugin "breaking change"?
> >
> > Today, everyone expects a "major version jump" to express breaking
> changes.
> > BUT, as explained above, that would be totally misleading here, and would
> > break the "customary law" that Major expresses Maven lineage.
> >
> > Ideas and opinions welcome.
> >
> > T
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Herve Boutemy <hb...@apache.org>.
using 4.x scheme looks simple and working: ok there is an exception with site, as there are always exceptions
what is important is system prerequisites history: remember for JDK requirement? same for Maven version requirement
just need to finish work on MPLUGIN-511 and we'll get the documentation automated
I hope we also have good error messages at runtime both in Maven 3 and 4
what makes me fear future headache is to decide if we maintain 2 branches (3.x and 4.x) in parallel of our ~50 plugins or if we just stop 3.x branch, or if we in general don't yet publish the 4.x branch unless there is a very good reason
or... any other idea that permits reasonable maintenance effort for us and reasonable service to our users community
Regards,
Hervé
On 2024/03/06 13:58:01 Tamás Cservenák wrote:
> Howdy,
>
> We have several topics that need to be discussed.
>
> I. Core Plugin Versioning
>
> History: When Maven2 was born, and started using plugins "as we know them
> today" (Maven 1 was a very different beast), the Core Plugin versions were
> started as 2.0 on purpose. Just check the Maven Central for historical
> versions, some examples:
> * clean
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> * compiler
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> * jar
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> * surefire
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> * dependency
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
>
> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> beginning. Later on, when Maven3 came to existence, it was able to use
> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> plugins" (Maven2 could not use them anymore). This was denoted by the "3.x"
> major plugin version jump.
>
> So far, we have no 4.x plugin release of anything (M releases do not
> count). But my question is the following:
>
> How should we distinguish similar changes for Maven4?
>
> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> will NOT be able to use anymore (will be incompatible). Similarly as
> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> capability for some time. But other ways it does not work, nor never worked
> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> Maven3 plugin).
>
> For me, the logical answer to this question is the use of major version
> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin
> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> plugin" (Maven2 incompatible).
>
> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> confuse the hell out of our users. At least that is what I think.
>
> II. Consequence: How to interpret Core plugin versions
>
> As can be seen above, so far the major version of the plugin was kinda
> showing "which Maven API level" is the plugin.
>
> So, it begs the question: HOW to interpret the Maven Core Plugin version?
>
> My interpretation was always: "shift it once left", meaning: Core plugin
> version "3.2.1" MEANS:
> - Maven API version: 3
> - Core Plugin version 2.1(.0)
>
> III. Consequence: How to express Core plugin "breaking change"?
>
> Today, everyone expects a "major version jump" to express breaking changes.
> BUT, as explained above, that would be totally misleading here, and would
> break the "customary law" that Major expresses Maven lineage.
>
> Ideas and opinions welcome.
>
> T
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Guillaume Nodet <gn...@apache.org>.
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 <gn...@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 <mi...@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-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
>
>
>
> --
> ------------------------
> Guillaume Nodet
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Think site got slowly replaced by other alternatives - even to document
mojos! - so today it is mainly about us and I also dont think limiting
doxia 2 to maven 4 has much issues, there is no real request from outside
for it AFAIK.
From a versioning standpoint I see really no reason to make a transitive
dep surfacing in a mojo, here it just highlights the site plugin is not
selfcontained as it should maybe be so maybe mvn4 could revisit it and try
to make our site integration back usbale by some users.
So I really see no reason to shout ourself in the foot for a single case
which is ultimately promished to more real redesign if we want to keep it
on the long run.
So let's start simple and if some users want it we'll sort it out as we
already did in some plugins which were multi versions friendly...but had a
single version if you follow ;).
Le ven. 8 mars 2024 à 21:18, Michael Osipov <mi...@apache.org> a écrit :
> I plan to publish an announcement *before* I update anything or bump
> reporting plugins to the (now) next minor version. People will always
> complain -- regardless of what you do -- if they are unhappy.
> I don't expect you to waste to time for site, just skip it mentally. I
> will take care.
>
> Am 2024-03-08 um 21:10 schrieb Tamás Cservenák:
> > Michael,
> >
> > I understand, but then all that remains is +10 or +100 in versions,
> > trickeries, or whatever...
> >
> > Be prepared for "this works with that but does not with that other" types
> > of JIRA...
> > And my guess is that the few who still use the site function of Maven
> will
> > simply drop it.
> > A big confusion is ahead, but I'd really not waste any (my at least)
> energy
> > on "what works with that in site" type of thing.
> >
> > This reminds me of Smylex, from Batman (1984).
> >
> > T
> >
> >
> > On Fri, Mar 8, 2024 at 9:01 PM Michael Osipov <mi...@apache.org>
> wrote:
> >
> >> Am 2024-03-08 um 20:56 schrieb Tamás Cservenák:
> >>> I agree with Gary,
> >>>
> >>> really really the simplest would be to NOT use Doxia 2 for Maven 3, as
> >>> basically that IS the "plugin breakage" we are soon facing.
> >>
> >> This is unacceptable for me because that breaks two years of ongoing
> >> effort. I cannot expect people to move off Maven 3 because of site
> >> generation. This is not a core issue since reporting has been removed
> >> from Maven Core in Maven 3 for good. Please DO NOT conflate what has
> >> been untangled 10+ years ago. I can/will use a minor release with a
> >> special section in the release notes since next major is unvailable.
> >>
> >> M
> >>
> >
>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Michael Osipov <mi...@apache.org>.
I plan to publish an announcement *before* I update anything or bump
reporting plugins to the (now) next minor version. People will always
complain -- regardless of what you do -- if they are unhappy.
I don't expect you to waste to time for site, just skip it mentally. I
will take care.
Am 2024-03-08 um 21:10 schrieb Tamás Cservenák:
> Michael,
>
> I understand, but then all that remains is +10 or +100 in versions,
> trickeries, or whatever...
>
> Be prepared for "this works with that but does not with that other" types
> of JIRA...
> And my guess is that the few who still use the site function of Maven will
> simply drop it.
> A big confusion is ahead, but I'd really not waste any (my at least) energy
> on "what works with that in site" type of thing.
>
> This reminds me of Smylex, from Batman (1984).
>
> T
>
>
> On Fri, Mar 8, 2024 at 9:01 PM Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2024-03-08 um 20:56 schrieb Tamás Cservenák:
>>> I agree with Gary,
>>>
>>> really really the simplest would be to NOT use Doxia 2 for Maven 3, as
>>> basically that IS the "plugin breakage" we are soon facing.
>>
>> This is unacceptable for me because that breaks two years of ongoing
>> effort. I cannot expect people to move off Maven 3 because of site
>> generation. This is not a core issue since reporting has been removed
>> from Maven Core in Maven 3 for good. Please DO NOT conflate what has
>> been untangled 10+ years ago. I can/will use a minor release with a
>> special section in the release notes since next major is unvailable.
>>
>> M
>>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
Sorry, 1989!
On Fri, Mar 8, 2024 at 9:10 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> Michael,
>
> I understand, but then all that remains is +10 or +100 in versions,
> trickeries, or whatever...
>
> Be prepared for "this works with that but does not with that other" types
> of JIRA...
> And my guess is that the few who still use the site function of Maven will
> simply drop it.
> A big confusion is ahead, but I'd really not waste any (my at least)
> energy on "what works with that in site" type of thing.
>
> This reminds me of Smylex, from Batman (1984).
>
> T
>
>
> On Fri, Mar 8, 2024 at 9:01 PM Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2024-03-08 um 20:56 schrieb Tamás Cservenák:
>> > I agree with Gary,
>> >
>> > really really the simplest would be to NOT use Doxia 2 for Maven 3, as
>> > basically that IS the "plugin breakage" we are soon facing.
>>
>> This is unacceptable for me because that breaks two years of ongoing
>> effort. I cannot expect people to move off Maven 3 because of site
>> generation. This is not a core issue since reporting has been removed
>> from Maven Core in Maven 3 for good. Please DO NOT conflate what has
>> been untangled 10+ years ago. I can/will use a minor release with a
>> special section in the release notes since next major is unvailable.
>>
>> M
>>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
Michael,
I understand, but then all that remains is +10 or +100 in versions,
trickeries, or whatever...
Be prepared for "this works with that but does not with that other" types
of JIRA...
And my guess is that the few who still use the site function of Maven will
simply drop it.
A big confusion is ahead, but I'd really not waste any (my at least) energy
on "what works with that in site" type of thing.
This reminds me of Smylex, from Batman (1984).
T
On Fri, Mar 8, 2024 at 9:01 PM Michael Osipov <mi...@apache.org> wrote:
> Am 2024-03-08 um 20:56 schrieb Tamás Cservenák:
> > I agree with Gary,
> >
> > really really the simplest would be to NOT use Doxia 2 for Maven 3, as
> > basically that IS the "plugin breakage" we are soon facing.
>
> This is unacceptable for me because that breaks two years of ongoing
> effort. I cannot expect people to move off Maven 3 because of site
> generation. This is not a core issue since reporting has been removed
> from Maven Core in Maven 3 for good. Please DO NOT conflate what has
> been untangled 10+ years ago. I can/will use a minor release with a
> special section in the release notes since next major is unvailable.
>
> M
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Michael Osipov <mi...@apache.org>.
Am 2024-03-08 um 20:56 schrieb Tamás Cservenák:
> I agree with Gary,
>
> really really the simplest would be to NOT use Doxia 2 for Maven 3, as
> basically that IS the "plugin breakage" we are soon facing.
This is unacceptable for me because that breaks two years of ongoing
effort. I cannot expect people to move off Maven 3 because of site
generation. This is not a core issue since reporting has been removed
from Maven Core in Maven 3 for good. Please DO NOT conflate what has
been untangled 10+ years ago. I can/will use a minor release with a
special section in the release notes since next major is unvailable.
M
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
I agree with Gary,
really really the simplest would be to NOT use Doxia 2 for Maven 3, as
basically that IS the "plugin breakage" we are soon facing.
T
On Fri, Mar 8, 2024 at 8:53 PM Gary Gregory <ga...@gmail.com> wrote:
> IMO, the old version + 0.10 is a recipe for confusion and explanations for
> this and that exception.
>
> Gary
>
> On Fri, Mar 8, 2024, 2:40 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>
> > Maarten,
> >
> > that would need a LOT of work, from maven plugin tools, IDEs and ALL the
> > stuff that _assumes_ that a plugin artifactId is either
> "maven-xxx-plugin"
> > or "xxx-maven-plugin".
> > Never looked into, but I guess that would be quite a big impact.
> >
> > T
> >
> > On Fri, Mar 8, 2024 at 8:22 PM Maarten Mulders <mt...@apache.org>
> > wrote:
> >
> > > It might've been proposed and rejected before, but how about
> > >
> > > 1. maven4-compiler-plugin
> > >
> > > -or-
> > >
> > > 2. maven-compiler-plugin (with maven4/maven5/etc classifier)
> > >
> > > In both scenario's, we could still use semantic versioning as we do
> > > right now, and as Maven users probably expect us to adhere to.
> > >
> > > Thanks,
> > >
> > >
> > > Maarten
> > >
> > > On 08/03/2024 20:10, Michael Osipov wrote:
> > > > Am 2024-03-08 um 17:20 schrieb Guillaume Nodet:
> > > >> 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....
> > > >
> > > > A four number system would contradict our approach. I guess a ceil to
> > > > the next 10 minor version is OK for that. So MSITE would be 3.20.x.
> > > > Applies to all reporting plugins as well and major will stay at 3.
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
Gary,
"core plugins" are controlled by us, and they always followed this
"standard" (version major was showing Maven API level).
But true, for EXTERNAL plugins, this will be quite an interesting thing.
They will probably solve the "migrated to Maven 4 API" by major version
bump.
Maven2 was "short lived" if you compare it to Maven3: roughly 2006-2009 (3
years?) vs 2010-today (14 years?)
And probably Maven3 made us "comfy" and easy to forget about _changes_ in
major version (like mvn2 vs mvn3 or mvn3 vs mvn4)
T
On Fri, Mar 8, 2024 at 9:33 PM Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Mar 8, 2024, 2:56 PM Michael Osipov <mi...@apache.org> wrote:
>
> > Am 2024-03-08 um 20:51 schrieb Gary Gregory:
> > > IMO, the old version + 0.10 is a recipe for confusion and explanations
> > for
> > > this and that exception.
> >
> > I totally agree with you, that is a horrible compromise. Do you see a
> > better way to reconcile both issues? I don't see any :-(
> >
>
> First let me say that I am a Maven fan and I don't want whatever I say here
> to be viewed as criticism of tech or people.
>
> From a user's point of view, using "maven4" as a plugin prefix is both
> obvious and simple to explain.
>
> Using a plugin version of 4.x or (gasp) 40.x is not great, mostly because
> my personal expectation is that it is the plugins' business to label
> themselves with whatever version they wants. The point "this is a core plug
> in, so..." is irrelevant to user's just like, as user, I should not need to
> know that "cd" is builtin a shell vs. a program like "grep" which is not.
>
> Gary
>
>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Mar 8, 2024, 2:56 PM Michael Osipov <mi...@apache.org> wrote:
> Am 2024-03-08 um 20:51 schrieb Gary Gregory:
> > IMO, the old version + 0.10 is a recipe for confusion and explanations
> for
> > this and that exception.
>
> I totally agree with you, that is a horrible compromise. Do you see a
> better way to reconcile both issues? I don't see any :-(
>
First let me say that I am a Maven fan and I don't want whatever I say here
to be viewed as criticism of tech or people.
From a user's point of view, using "maven4" as a plugin prefix is both
obvious and simple to explain.
Using a plugin version of 4.x or (gasp) 40.x is not great, mostly because
my personal expectation is that it is the plugins' business to label
themselves with whatever version they wants. The point "this is a core plug
in, so..." is irrelevant to user's just like, as user, I should not need to
know that "cd" is builtin a shell vs. a program like "grep" which is not.
Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Michael Osipov <mi...@apache.org>.
Am 2024-03-08 um 20:51 schrieb Gary Gregory:
> IMO, the old version + 0.10 is a recipe for confusion and explanations for
> this and that exception.
I totally agree with you, that is a horrible compromise. Do you see a
better way to reconcile both issues? I don't see any :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Gary Gregory <ga...@gmail.com>.
IMO, the old version + 0.10 is a recipe for confusion and explanations for
this and that exception.
Gary
On Fri, Mar 8, 2024, 2:40 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> Maarten,
>
> that would need a LOT of work, from maven plugin tools, IDEs and ALL the
> stuff that _assumes_ that a plugin artifactId is either "maven-xxx-plugin"
> or "xxx-maven-plugin".
> Never looked into, but I guess that would be quite a big impact.
>
> T
>
> On Fri, Mar 8, 2024 at 8:22 PM Maarten Mulders <mt...@apache.org>
> wrote:
>
> > It might've been proposed and rejected before, but how about
> >
> > 1. maven4-compiler-plugin
> >
> > -or-
> >
> > 2. maven-compiler-plugin (with maven4/maven5/etc classifier)
> >
> > In both scenario's, we could still use semantic versioning as we do
> > right now, and as Maven users probably expect us to adhere to.
> >
> > Thanks,
> >
> >
> > Maarten
> >
> > On 08/03/2024 20:10, Michael Osipov wrote:
> > > Am 2024-03-08 um 17:20 schrieb Guillaume Nodet:
> > >> 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....
> > >
> > > A four number system would contradict our approach. I guess a ceil to
> > > the next 10 minor version is OK for that. So MSITE would be 3.20.x.
> > > Applies to all reporting plugins as well and major will stay at 3.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
Maarten,
that would need a LOT of work, from maven plugin tools, IDEs and ALL the
stuff that _assumes_ that a plugin artifactId is either "maven-xxx-plugin"
or "xxx-maven-plugin".
Never looked into, but I guess that would be quite a big impact.
T
On Fri, Mar 8, 2024 at 8:22 PM Maarten Mulders <mt...@apache.org>
wrote:
> It might've been proposed and rejected before, but how about
>
> 1. maven4-compiler-plugin
>
> -or-
>
> 2. maven-compiler-plugin (with maven4/maven5/etc classifier)
>
> In both scenario's, we could still use semantic versioning as we do
> right now, and as Maven users probably expect us to adhere to.
>
> Thanks,
>
>
> Maarten
>
> On 08/03/2024 20:10, Michael Osipov wrote:
> > Am 2024-03-08 um 17:20 schrieb Guillaume Nodet:
> >> 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....
> >
> > A four number system would contradict our approach. I guess a ceil to
> > the next 10 minor version is OK for that. So MSITE would be 3.20.x.
> > Applies to all reporting plugins as well and major will stay at 3.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Maarten Mulders <mt...@apache.org>.
It might've been proposed and rejected before, but how about
1. maven4-compiler-plugin
-or-
2. maven-compiler-plugin (with maven4/maven5/etc classifier)
In both scenario's, we could still use semantic versioning as we do
right now, and as Maven users probably expect us to adhere to.
Thanks,
Maarten
On 08/03/2024 20:10, Michael Osipov wrote:
> Am 2024-03-08 um 17:20 schrieb Guillaume Nodet:
>> 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....
>
> A four number system would contradict our approach. I guess a ceil to
> the next 10 minor version is OK for that. So MSITE would be 3.20.x.
> Applies to all reporting plugins as well and major will stay at 3.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Michael Osipov <mi...@apache.org>.
Am 2024-03-08 um 17:20 schrieb Guillaume Nodet:
> 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....
A four number system would contradict our approach. I guess a ceil to
the next 10 minor version is OK for that. So MSITE would be 3.20.x.
Applies to all reporting plugins as well and major will stay at 3.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Guillaume Nodet <gn...@apache.org>.
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 <mi...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Anders Hammar <an...@hammar.net>.
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 <mi...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Michael,
Site 4.0.0 does not exist, there are only milestones (so no guarantee given
in such a release) so not a big deal IMHO, we can align on Tamas proposal
and just do a 3.(n+1) if we want to propose the changes to maven 3 (no big
opinion on this one).
So proposal sounds good to me: $maven.$pluginMajor.$minor.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 8 mars 2024 à 11:51, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Howdy,
>
> First, 4.0 is not out yet (check my remark in the initial mail "M releases
> do not count").
>
> Second, is there a plugin out there that also includes a report?
> (or in other words, you remember I was insisting to SPLIT OUT all the
> report stuff out of plugins)
>
> As if there is no such plugin, we deal with them just like explained above
> in case of "breaking changes":
> basically report-plugins will have breaking changes and will require new
> site stuff...
>
> If there is a plugin that includes report as well, report MUST be split out
> as the first step.
>
> T
>
> On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov <mi...@apache.org>
> wrote:
>
> > Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
> > > 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?
> >
> > See Maven Site Plugin 4.0, contains fundemantal changes in the
> > background, cannot keep 3.x. Same will apply to almost all of our
> > reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to
> > Maven 4. How do deal with that?
> >
> > M
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Matthias Bünger <ru...@web.de.INVALID>.
+1
Am 08.03.2024 um 13:00 schrieb Tamás Cservenák:
> 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 plugin release notes, plugin announce
> and plugin site
>
> (new) IV. Doxia should be handled similar to Resolver
> - Doxia 1.x is Maven 3 (as today, m-site-p 3.x is Maven3 plugin and uses
> Doxia 1.x stack)
> - Doxia 2.x is Maven 4 (in future, m-site-p 4.x will be Maven4 plugin and
> will use Doxia 2.x stack)
> As this then solves all the problems Michael brought up rightfully.
>
> T
>
>
>
> On Fri, Mar 8, 2024 at 12:27 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>
>> And a short addendum:
>>
>> Given, today there are still no Maven 4.x plugins nor Doxia 2.x reports
>> out there (released), what if, we follow Michael intent BUT with a slight
>> "bend":
>> - the new Maven Site plugin that uses Doxia 2.0.0 and would carry version
>> 4.0.0 (to be released) **should be Maven4 plugin**
>> - this implies that all reports stuff that will Doxia 2.0.0 MUST BE Maven4
>> plugins as well
>> - basically, leave Doxia 1.x for Maven3 as is, and use Doxia 2.x for Maven4
>>
>> T
>>
>> On Fri, Mar 8, 2024 at 12:20 PM Tamás Cservenák <ta...@cservenak.net>
>> wrote:
>>
>>> Just to clarify, explain myself but also FTR on thread:
>>>
>>> in case of report-plugins we basically have TWO requirements (or deps):
>>> - maven API level
>>> - doxia API level (that with 2.0.0 contains breaking changes)
>>>
>>> Basically, Maven4 supports 4.x plugins (that use new API) but also
>>> supports running 3,x plugins (in "compat" mode, just like today, as there
>>> are still no 4.x plugins out there).
>>> But Doxia introduces hard breakage, as far as I understand (correct me
>>> here if I am wrong), there is no "Doxia 2.x backward compat support for
>>> Doxia 1.x clients"?
>>>
>>> Given Doxia 1.x is being phased out, and unlike for Maven API (where we
>>> do want and will maintain 3.x and 4.x plugin versions in parallel), this is
>>> not happening with reports/doxia.
>>> We do not want any Doxia 1.x report to be released, right?
>>>
>>> This also implies that a build that does use reports, cannot "gradually"
>>> migrate to Doxia 2.0.0, no?
>>> It is all or nothing, no? So either a new site plugin with Doxia 2.x or
>>> an old site plugin with Doxia 1.x?
>>>
>>> T
>>>
>>> On Fri, Mar 8, 2024 at 11:50 AM Tamás Cservenák <ta...@cservenak.net>
>>> wrote:
>>>
>>>> Howdy,
>>>>
>>>> First, 4.0 is not out yet (check my remark in the initial mail "M
>>>> releases do not count").
>>>>
>>>> Second, is there a plugin out there that also includes a report?
>>>> (or in other words, you remember I was insisting to SPLIT OUT all the
>>>> report stuff out of plugins)
>>>>
>>>> As if there is no such plugin, we deal with them just like explained
>>>> above in case of "breaking changes":
>>>> basically report-plugins will have breaking changes and will require new
>>>> site stuff...
>>>>
>>>> If there is a plugin that includes report as well, report MUST be
>>>> split out as the first step.
>>>>
>>>> T
>>>>
>>>> On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov <mi...@apache.org>
>>>> wrote:
>>>>
>>>>> Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
>>>>>> 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?
>>>>> See Maven Site Plugin 4.0, contains fundemantal changes in the
>>>>> background, cannot keep 3.x. Same will apply to almost all of our
>>>>> reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to
>>>>> Maven 4. How do deal with that?
>>>>>
>>>>> M
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 without any strong opinion on doxia 2 for maven 3 in the future (no
blocker IMHO but not the baseline too)
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 8 mars 2024 à 13:00, 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 plugin release notes, plugin announce
> and plugin site
>
> (new) IV. Doxia should be handled similar to Resolver
> - Doxia 1.x is Maven 3 (as today, m-site-p 3.x is Maven3 plugin and uses
> Doxia 1.x stack)
> - Doxia 2.x is Maven 4 (in future, m-site-p 4.x will be Maven4 plugin and
> will use Doxia 2.x stack)
> As this then solves all the problems Michael brought up rightfully.
>
> T
>
>
>
> On Fri, Mar 8, 2024 at 12:27 PM Tamás Cservenák <ta...@cservenak.net>
> wrote:
>
> > And a short addendum:
> >
> > Given, today there are still no Maven 4.x plugins nor Doxia 2.x reports
> > out there (released), what if, we follow Michael intent BUT with a slight
> > "bend":
> > - the new Maven Site plugin that uses Doxia 2.0.0 and would carry version
> > 4.0.0 (to be released) **should be Maven4 plugin**
> > - this implies that all reports stuff that will Doxia 2.0.0 MUST BE
> Maven4
> > plugins as well
> > - basically, leave Doxia 1.x for Maven3 as is, and use Doxia 2.x for
> Maven4
> >
> > T
> >
> > On Fri, Mar 8, 2024 at 12:20 PM Tamás Cservenák <ta...@cservenak.net>
> > wrote:
> >
> >> Just to clarify, explain myself but also FTR on thread:
> >>
> >> in case of report-plugins we basically have TWO requirements (or deps):
> >> - maven API level
> >> - doxia API level (that with 2.0.0 contains breaking changes)
> >>
> >> Basically, Maven4 supports 4.x plugins (that use new API) but also
> >> supports running 3,x plugins (in "compat" mode, just like today, as
> there
> >> are still no 4.x plugins out there).
> >> But Doxia introduces hard breakage, as far as I understand (correct me
> >> here if I am wrong), there is no "Doxia 2.x backward compat support for
> >> Doxia 1.x clients"?
> >>
> >> Given Doxia 1.x is being phased out, and unlike for Maven API (where we
> >> do want and will maintain 3.x and 4.x plugin versions in parallel),
> this is
> >> not happening with reports/doxia.
> >> We do not want any Doxia 1.x report to be released, right?
> >>
> >> This also implies that a build that does use reports, cannot "gradually"
> >> migrate to Doxia 2.0.0, no?
> >> It is all or nothing, no? So either a new site plugin with Doxia 2.x or
> >> an old site plugin with Doxia 1.x?
> >>
> >> T
> >>
> >> On Fri, Mar 8, 2024 at 11:50 AM Tamás Cservenák <ta...@cservenak.net>
> >> wrote:
> >>
> >>> Howdy,
> >>>
> >>> First, 4.0 is not out yet (check my remark in the initial mail "M
> >>> releases do not count").
> >>>
> >>> Second, is there a plugin out there that also includes a report?
> >>> (or in other words, you remember I was insisting to SPLIT OUT all the
> >>> report stuff out of plugins)
> >>>
> >>> As if there is no such plugin, we deal with them just like explained
> >>> above in case of "breaking changes":
> >>> basically report-plugins will have breaking changes and will require
> new
> >>> site stuff...
> >>>
> >>> If there is a plugin that includes report as well, report MUST be
> >>> split out as the first step.
> >>>
> >>> T
> >>>
> >>> On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov <mi...@apache.org>
> >>> wrote:
> >>>
> >>>> Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
> >>>> > 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?
> >>>>
> >>>> See Maven Site Plugin 4.0, contains fundemantal changes in the
> >>>> background, cannot keep 3.x. Same will apply to almost all of our
> >>>> reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to
> >>>> Maven 4. How do deal with that?
> >>>>
> >>>> M
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 plugin release notes, plugin announce
and plugin site
(new) IV. Doxia should be handled similar to Resolver
- Doxia 1.x is Maven 3 (as today, m-site-p 3.x is Maven3 plugin and uses
Doxia 1.x stack)
- Doxia 2.x is Maven 4 (in future, m-site-p 4.x will be Maven4 plugin and
will use Doxia 2.x stack)
As this then solves all the problems Michael brought up rightfully.
T
On Fri, Mar 8, 2024 at 12:27 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> And a short addendum:
>
> Given, today there are still no Maven 4.x plugins nor Doxia 2.x reports
> out there (released), what if, we follow Michael intent BUT with a slight
> "bend":
> - the new Maven Site plugin that uses Doxia 2.0.0 and would carry version
> 4.0.0 (to be released) **should be Maven4 plugin**
> - this implies that all reports stuff that will Doxia 2.0.0 MUST BE Maven4
> plugins as well
> - basically, leave Doxia 1.x for Maven3 as is, and use Doxia 2.x for Maven4
>
> T
>
> On Fri, Mar 8, 2024 at 12:20 PM Tamás Cservenák <ta...@cservenak.net>
> wrote:
>
>> Just to clarify, explain myself but also FTR on thread:
>>
>> in case of report-plugins we basically have TWO requirements (or deps):
>> - maven API level
>> - doxia API level (that with 2.0.0 contains breaking changes)
>>
>> Basically, Maven4 supports 4.x plugins (that use new API) but also
>> supports running 3,x plugins (in "compat" mode, just like today, as there
>> are still no 4.x plugins out there).
>> But Doxia introduces hard breakage, as far as I understand (correct me
>> here if I am wrong), there is no "Doxia 2.x backward compat support for
>> Doxia 1.x clients"?
>>
>> Given Doxia 1.x is being phased out, and unlike for Maven API (where we
>> do want and will maintain 3.x and 4.x plugin versions in parallel), this is
>> not happening with reports/doxia.
>> We do not want any Doxia 1.x report to be released, right?
>>
>> This also implies that a build that does use reports, cannot "gradually"
>> migrate to Doxia 2.0.0, no?
>> It is all or nothing, no? So either a new site plugin with Doxia 2.x or
>> an old site plugin with Doxia 1.x?
>>
>> T
>>
>> On Fri, Mar 8, 2024 at 11:50 AM Tamás Cservenák <ta...@cservenak.net>
>> wrote:
>>
>>> Howdy,
>>>
>>> First, 4.0 is not out yet (check my remark in the initial mail "M
>>> releases do not count").
>>>
>>> Second, is there a plugin out there that also includes a report?
>>> (or in other words, you remember I was insisting to SPLIT OUT all the
>>> report stuff out of plugins)
>>>
>>> As if there is no such plugin, we deal with them just like explained
>>> above in case of "breaking changes":
>>> basically report-plugins will have breaking changes and will require new
>>> site stuff...
>>>
>>> If there is a plugin that includes report as well, report MUST be
>>> split out as the first step.
>>>
>>> T
>>>
>>> On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov <mi...@apache.org>
>>> wrote:
>>>
>>>> Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
>>>> > 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?
>>>>
>>>> See Maven Site Plugin 4.0, contains fundemantal changes in the
>>>> background, cannot keep 3.x. Same will apply to almost all of our
>>>> reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to
>>>> Maven 4. How do deal with that?
>>>>
>>>> M
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
And a short addendum:
Given, today there are still no Maven 4.x plugins nor Doxia 2.x reports out
there (released), what if, we follow Michael intent BUT with a slight
"bend":
- the new Maven Site plugin that uses Doxia 2.0.0 and would carry version
4.0.0 (to be released) **should be Maven4 plugin**
- this implies that all reports stuff that will Doxia 2.0.0 MUST BE Maven4
plugins as well
- basically, leave Doxia 1.x for Maven3 as is, and use Doxia 2.x for Maven4
T
On Fri, Mar 8, 2024 at 12:20 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> Just to clarify, explain myself but also FTR on thread:
>
> in case of report-plugins we basically have TWO requirements (or deps):
> - maven API level
> - doxia API level (that with 2.0.0 contains breaking changes)
>
> Basically, Maven4 supports 4.x plugins (that use new API) but also
> supports running 3,x plugins (in "compat" mode, just like today, as there
> are still no 4.x plugins out there).
> But Doxia introduces hard breakage, as far as I understand (correct me
> here if I am wrong), there is no "Doxia 2.x backward compat support for
> Doxia 1.x clients"?
>
> Given Doxia 1.x is being phased out, and unlike for Maven API (where we do
> want and will maintain 3.x and 4.x plugin versions in parallel), this is
> not happening with reports/doxia.
> We do not want any Doxia 1.x report to be released, right?
>
> This also implies that a build that does use reports, cannot "gradually"
> migrate to Doxia 2.0.0, no?
> It is all or nothing, no? So either a new site plugin with Doxia 2.x or an
> old site plugin with Doxia 1.x?
>
> T
>
> On Fri, Mar 8, 2024 at 11:50 AM Tamás Cservenák <ta...@cservenak.net>
> wrote:
>
>> Howdy,
>>
>> First, 4.0 is not out yet (check my remark in the initial mail "M
>> releases do not count").
>>
>> Second, is there a plugin out there that also includes a report?
>> (or in other words, you remember I was insisting to SPLIT OUT all the
>> report stuff out of plugins)
>>
>> As if there is no such plugin, we deal with them just like explained
>> above in case of "breaking changes":
>> basically report-plugins will have breaking changes and will require new
>> site stuff...
>>
>> If there is a plugin that includes report as well, report MUST be
>> split out as the first step.
>>
>> T
>>
>> On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov <mi...@apache.org>
>> wrote:
>>
>>> Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
>>> > 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?
>>>
>>> See Maven Site Plugin 4.0, contains fundemantal changes in the
>>> background, cannot keep 3.x. Same will apply to almost all of our
>>> reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to
>>> Maven 4. How do deal with that?
>>>
>>> M
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
Just to clarify, explain myself but also FTR on thread:
in case of report-plugins we basically have TWO requirements (or deps):
- maven API level
- doxia API level (that with 2.0.0 contains breaking changes)
Basically, Maven4 supports 4.x plugins (that use new API) but also supports
running 3,x plugins (in "compat" mode, just like today, as there are still
no 4.x plugins out there).
But Doxia introduces hard breakage, as far as I understand (correct me here
if I am wrong), there is no "Doxia 2.x backward compat support for Doxia
1.x clients"?
Given Doxia 1.x is being phased out, and unlike for Maven API (where we do
want and will maintain 3.x and 4.x plugin versions in parallel), this is
not happening with reports/doxia.
We do not want any Doxia 1.x report to be released, right?
This also implies that a build that does use reports, cannot "gradually"
migrate to Doxia 2.0.0, no?
It is all or nothing, no? So either a new site plugin with Doxia 2.x or an
old site plugin with Doxia 1.x?
T
On Fri, Mar 8, 2024 at 11:50 AM Tamás Cservenák <ta...@cservenak.net> wrote:
> Howdy,
>
> First, 4.0 is not out yet (check my remark in the initial mail "M releases
> do not count").
>
> Second, is there a plugin out there that also includes a report?
> (or in other words, you remember I was insisting to SPLIT OUT all the
> report stuff out of plugins)
>
> As if there is no such plugin, we deal with them just like explained above
> in case of "breaking changes":
> basically report-plugins will have breaking changes and will require new
> site stuff...
>
> If there is a plugin that includes report as well, report MUST be
> split out as the first step.
>
> T
>
> On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov <mi...@apache.org>
> wrote:
>
>> Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
>> > 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?
>>
>> See Maven Site Plugin 4.0, contains fundemantal changes in the
>> background, cannot keep 3.x. Same will apply to almost all of our
>> reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to
>> Maven 4. How do deal with that?
>>
>> M
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
First, 4.0 is not out yet (check my remark in the initial mail "M releases
do not count").
Second, is there a plugin out there that also includes a report?
(or in other words, you remember I was insisting to SPLIT OUT all the
report stuff out of plugins)
As if there is no such plugin, we deal with them just like explained above
in case of "breaking changes":
basically report-plugins will have breaking changes and will require new
site stuff...
If there is a plugin that includes report as well, report MUST be split out
as the first step.
T
On Fri, Mar 8, 2024 at 11:29 AM Michael Osipov <mi...@apache.org> wrote:
> Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
> > 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?
>
> See Maven Site Plugin 4.0, contains fundemantal changes in the
> background, cannot keep 3.x. Same will apply to almost all of our
> reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to
> Maven 4. How do deal with that?
>
> M
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Michael Osipov <mi...@apache.org>.
Am 2024-03-08 um 11:19 schrieb Tamás Cservenák:
> 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?
See Maven Site Plugin 4.0, contains fundemantal changes in the
background, cannot keep 3.x. Same will apply to almost all of our
reporting plugins which is caused by Doxia 2.0.0. Totally unrelated to
Maven 4. How do deal with that?
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <mi...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <mi...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [DISCUSS] Maven Core Plugins versioning
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org