Re: [DISCUSS] Maven Core Plugins versioning

[Romain Manni-Bucau]

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  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Core Plugins versioning

[Herve Boutemy]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

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  wrote:

> On Fri, Mar 8, 2024, 2:56 PM Michael Osipov  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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSS] Maven Core Plugins versioning

[Gary Gregory]

On Fri, Mar 8, 2024, 2:56 PM Michael Osipov  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Core Plugins versioning

[Romain Manni-Bucau]

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  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 
> 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

[Michael Osipov]

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  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

[Tamás Cservenák]

Sorry, 1989!

On Fri, Mar 8, 2024 at 9:10 PM Tamás Cservenák  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  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

[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  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

[Michael Osipov]

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

[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.

T

On Fri, Mar 8, 2024 at 8:53 PM Gary Gregory  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  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 
> > 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-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Maven Core Plugins versioning

[Michael Osipov]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Gary Gregory]

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  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 
> 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-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

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 
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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Core Plugins versioning

[Maarten Mulders]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Michael Osipov]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Guillaume Nodet]

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  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  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  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  wrote:
> > >
> > >> This is a general problem and cannot be solved. As soon as you need to
> > >> break the plugin compat you need to bump the major version. That
> > >> breakage does not need to be related to Maven at all.
> > >> Upshot: No matter what you do, you will do it wrong. I would rely on
> > >> MPLUGIN foo to manage he compat history.
> > >>
> > >> M
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >>
>
>
>
> --
> 
> Guillaume Nodet



-- 

Guillaume Nodet

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[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

Guillaume

Le ven. 8 mars 2024 à 11:19, Tamás Cservenák  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  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  wrote:
> >
> >> This is a general problem and cannot be solved. As soon as you need to
> >> break the plugin compat you need to bump the major version. That
> >> breakage does not need to be related to Maven at all.
> >> Upshot: No matter what you do, you will do it wrong. I would rely on
> >> MPLUGIN foo to manage he compat history.
> >>
> >> M
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>



-- 

Guillaume Nodet

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Matthias Bünger]

+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  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 
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 
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 
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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Romain Manni-Bucau]

+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  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 
> 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 
> > 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 
> >> 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
> >&

Re: [DISCUSS] Maven Core Plugins versioning

[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  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 
> 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 
>> 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 
>>> 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-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>
>>>

Re: [DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

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  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 
> 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 
>> 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-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>

Re: [DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

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  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 
> 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-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>

Re: [DISCUSS] Maven Core Plugins versioning

[Romain Manni-Bucau]

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  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 
> 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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>

Re: [DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

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  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: [DISCUSS] Maven Core Plugins versioning

[Michael Osipov]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Anders Hammar]

Sounds good to me.

/Anders (mobile)

Den fre 8 mars 2024 11:19Tamás Cservenák  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 
> 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 
> wrote:
> >
> >> This is a general problem and cannot be solved. As soon as you need to
> >> break the plugin compat you need to bump the major version. That
> >> breakage does not need to be related to Maven at all.
> >> Upshot: No matter what you do, you will do it wrong. I would rely on
> >> MPLUGIN foo to manage he compat history.
> >>
> >> M
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>

Re: [DISCUSS] Maven Core Plugins versioning

[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 release notes, announce and site

T

On Thu, Mar 7, 2024 at 9:23 AM Tamás Cservenák  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  wrote:
>
>> This is a general problem and cannot be solved. As soon as you need to
>> break the plugin compat you need to bump the major version. That
>> breakage does not need to be related to Maven at all.
>> Upshot: No matter what you do, you will do it wrong. I would rely on
>> MPLUGIN foo to manage he compat history.
>>
>> M
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: [DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

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  wrote:

> This is a general problem and cannot be solved. As soon as you need to
> break the plugin compat you need to bump the major version. That
> breakage does not need to be related to Maven at all.
> Upshot: No matter what you do, you will do it wrong. I would rely on
> MPLUGIN foo to manage he compat history.
>
> M
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Core Plugins versioning

[Michael Osipov]

This is a general problem and cannot be solved. As soon as you need to 
break the plugin compat you need to bump the major version. That 
breakage does not need to be related to Maven at all.
Upshot: No matter what you do, you will do it wrong. I would rely on 
MPLUGIN foo to manage he compat history.


M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Matthias bünger]

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 :
> 
> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Romain Manni-Bucau]

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  a écrit :

> +1  to that definition
>
> On Wed, Mar 6, 2024 at 3:14 PM Konrad Windszus  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  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 
> > 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
> >

Re: [DISCUSS] Maven Core Plugins versioning

[Konrad Windszus]

This is slightly differently described on https://maven.apache.org/plugins/

Core pluginsPlugins 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  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  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 
>> 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-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 

Re: [DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

+1  to that definition

On Wed, Mar 6, 2024 at 3:14 PM Konrad Windszus  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  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 
> 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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>

Re: [DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

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  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 
> 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Core Plugins versioning

[Konrad Windszus]

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  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  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Re: [DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

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 
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  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

[Konrad Windszus]

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  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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Gary Gregory]

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  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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Maven Core Plugins versioning

[Romain Manni-Bucau]

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  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
>

[DISCUSS] Maven Core Plugins versioning

[Tamás Cservenák]

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: [DISCUSSION] Apache Maven plugins versioning

[Romain Manni-Bucau]

So you mean maven 5 will need to rename and rerelease all plugins even if
they will be compatible thanks the policy versioning rule + new API?
Npm and webpacks are not great rerefences since they don't aim at being
stable as we intend.
Look at javaee (before the jakarta big bang which broke this assumption):
you can use v4 and run on v7 and several parts were not even re-released so
not sure the related work is worth it.

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 lun. 27 mars 2023 à 19:22, Benjamin Marwell  a
écrit :

> The advantage is simple.
> With "maven4" in the module name, you don't need a compatibility matrix on
> every plugins homepage or readme.
>
> Just look at npm modules and webpack... Tables over tables...
>
>
>
>
> On Sun, 26 Mar 2023, 19:29 Michael Osipov,  wrote:
>
> > Am 2023-03-26 um 19:02 schrieb Romain Manni-Bucau:
> > > @Benjamin what's the addtion of the "4" except looking weird after 1
> > > version since you use semver? It forces 2 changes instead of one
> without
> > > anything else explicit IMHO.
> >
> > I fully second that!
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSSION] Apache Maven plugins versioning

[Benjamin Marwell]

The advantage is simple.
With "maven4" in the module name, you don't need a compatibility matrix on
every plugins homepage or readme.

Just look at npm modules and webpack... Tables over tables...




On Sun, 26 Mar 2023, 19:29 Michael Osipov,  wrote:

> Am 2023-03-26 um 19:02 schrieb Romain Manni-Bucau:
> > @Benjamin what's the addtion of the "4" except looking weird after 1
> > version since you use semver? It forces 2 changes instead of one without
> > anything else explicit IMHO.
>
> I fully second that!
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSSION] Apache Maven plugins versioning

[Michael Osipov]

Am 2023-03-26 um 19:02 schrieb Romain Manni-Bucau:

@Benjamin what's the addtion of the "4" except looking weird after 1
version since you use semver? It forces 2 changes instead of one without
anything else explicit IMHO.


I fully second that!


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSSION] Apache Maven plugins versioning

[Romain Manni-Bucau]

@Benjamin what's the addtion of the "4" except looking weird after 1
version since you use semver? It forces 2 changes instead of one without
anything else explicit 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 dim. 26 mars 2023 à 18:16, Benjamin Marwell  a
écrit :

> +1 to your proposal
>
> org.apache.maven:maven4-xyz-plugin:
>
> I don't think it would cause too much trouble as Maven APIs will love for a
> few years. It will only occasionally break when a new major Maven release
> is published. I can live with that.
>
> Also, maven 3 plugins will be compatible for a while.
>
>
>
>
> On Thu, 23 Mar 2023, 20:58 Slawomir Jaranowski, 
> wrote:
>
> > Hi,
> >
> > I know that historically plugin versions like 2.x was dedicated to Maven
> > 2.x and versions 3.x is for Maven 3.x.
> >
> > We don't have any written documentation about it (or I can't find it), it
> > looks like a traditional agreement.
> >
> > Nowadays Semantic Versioning is very popular and it is understood by
> people
> > and by automatic tools.
> > In many cases we use versions which look like Semantic Versioning
> (x.y.z) -
> > but internally we try to classify it in different ways.
> >
> > When we connect the plugins version with the Maven version as the major
> > version,
> > we have difficulty introducing breaking changes for plugins for the same
> > Maven version.
> > Also we can introduce many misunderstandings which version contains new
> > features and which only bug fixes.
> >
> > Authors of plugins outside Maven core in many cases don't use 3.x as for
> > Maven 3 and so on.
> >
> > One of the propositions can be - use Semantic Versioning as is described
> > and put a Maven version in the artifact name of the plugin.
> >
> > So we can have:
> >
> > maven4-XXX-plugin - for core plugins
> > XXX-maven4-plugin - for external plugins
> >
> > Additionally Maven 4 will have a new Api which is incompatible with Maven
> > 3, when we have the target Maven version in artifact it will be easier to
> > transition plugins from 3 to 4 and so on.
> >
> > Simply in many cases business logic which plugin provides can be
> extracted
> > to a common module and next two modules will provide plugins for specific
> > Maven.
> > It can help maintain one plugin for many Maven versions.
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: [DISCUSSION] Apache Maven plugins versioning

[Benjamin Marwell]

+1 to your proposal

org.apache.maven:maven4-xyz-plugin:

I don't think it would cause too much trouble as Maven APIs will love for a
few years. It will only occasionally break when a new major Maven release
is published. I can live with that.

Also, maven 3 plugins will be compatible for a while.




On Thu, 23 Mar 2023, 20:58 Slawomir Jaranowski, 
wrote:

> Hi,
>
> I know that historically plugin versions like 2.x was dedicated to Maven
> 2.x and versions 3.x is for Maven 3.x.
>
> We don't have any written documentation about it (or I can't find it), it
> looks like a traditional agreement.
>
> Nowadays Semantic Versioning is very popular and it is understood by people
> and by automatic tools.
> In many cases we use versions which look like Semantic Versioning (x.y.z) -
> but internally we try to classify it in different ways.
>
> When we connect the plugins version with the Maven version as the major
> version,
> we have difficulty introducing breaking changes for plugins for the same
> Maven version.
> Also we can introduce many misunderstandings which version contains new
> features and which only bug fixes.
>
> Authors of plugins outside Maven core in many cases don't use 3.x as for
> Maven 3 and so on.
>
> One of the propositions can be - use Semantic Versioning as is described
> and put a Maven version in the artifact name of the plugin.
>
> So we can have:
>
> maven4-XXX-plugin - for core plugins
> XXX-maven4-plugin - for external plugins
>
> Additionally Maven 4 will have a new Api which is incompatible with Maven
> 3, when we have the target Maven version in artifact it will be easier to
> transition plugins from 3 to 4 and so on.
>
> Simply in many cases business logic which plugin provides can be extracted
> to a common module and next two modules will provide plugins for specific
> Maven.
> It can help maintain one plugin for many Maven versions.
>
>
> --
> Sławomir Jaranowski
>

Re: [DISCUSSION] Apache Maven plugins versioning

[Michael Osipov]

Am 2023-03-23 um 20:57 schrieb Slawomir Jaranowski:

Hi,

I know that historically plugin versions like 2.x was dedicated to Maven
2.x and versions 3.x is for Maven 3.x.

We don't have any written documentation about it (or I can't find it), it
looks like a traditional agreement.


I wouldn't tie it anymore. It just needs proper documentation. I will 
soon bump *all* reporting plugins to new major versions because the 
Doxia 2.0.0 stack is coming. Same Maven version, but Doxia 1.x will be 
left behind. This CANNOT happen in a minor version.


SemVer has its issues, it does not support post-release qualifiers, I 
consider it, by looking at the EBNF too complex.


We have also this: 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html


M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSSION] Apache Maven plugins versioning

[Slawomir Jaranowski]

Hi

We can also publish in plugin documentation history of Maven API and JDK
requirements [1]

I still think we should make some decisions on it ... and publish to be
clear in such matters.

We have m-site-p in version 4.0.0-M6 - does mean that should be used with
Maven 4, it still require Maven 3.2.5 [2]

[1]
https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/plugin-info.html
[2] https://maven.apache.org/plugins/maven-site-plugin/plugin-info.html


czw., 23 mar 2023 o 20:57 Slawomir Jaranowski 
napisał(a):

> Hi,
>
> I know that historically plugin versions like 2.x was dedicated to Maven
> 2.x and versions 3.x is for Maven 3.x.
>
> We don't have any written documentation about it (or I can't find it), it
> looks like a traditional agreement.
>
> Nowadays Semantic Versioning is very popular and it is understood by
> people and by automatic tools.
> In many cases we use versions which look like Semantic Versioning (x.y.z)
> - but internally we try to classify it in different ways.
>
> When we connect the plugins version with the Maven version as the major
> version,
> we have difficulty introducing breaking changes for plugins for the same
> Maven version.
> Also we can introduce many misunderstandings which version contains new
> features and which only bug fixes.
>
> Authors of plugins outside Maven core in many cases don't use 3.x as for
> Maven 3 and so on.
>
> One of the propositions can be - use Semantic Versioning as is described
> and put a Maven version in the artifact name of the plugin.
>
> So we can have:
>
> maven4-XXX-plugin - for core plugins
> XXX-maven4-plugin - for external plugins
>
> Additionally Maven 4 will have a new Api which is incompatible with Maven
> 3, when we have the target Maven version in artifact it will be easier to
> transition plugins from 3 to 4 and so on.
>
> Simply in many cases business logic which plugin provides can be extracted
> to a common module and next two modules will provide plugins for specific
> Maven.
> It can help maintain one plugin for many Maven versions.
>
>
> --
> Sławomir Jaranowski
>


-- 
Sławomir Jaranowski

Re: [DISCUSSION] Apache Maven plugins versioning

[Elliotte Rusty Harold]

I vote +1 on just using semver, more or less, and calling it a day.

We really shouldn't change artifact IDs unless we're changing
everything else too so it's basically a new artifact. Even if it is a
completely new plugin, it's likely that in the future it will want to
support Maven 5+ so let's not bake the Maven version into the artifact
ID. They should be able to evolve more independently. The Maven
coordinates are not the right place to indicate which Maven versions a
given plugin supports.

On Thu, Mar 23, 2023 at 3:58 PM Slawomir Jaranowski
 wrote:
>
> Hi,
>
> I know that historically plugin versions like 2.x was dedicated to Maven
> 2.x and versions 3.x is for Maven 3.x.
>
> We don't have any written documentation about it (or I can't find it), it
> looks like a traditional agreement.
>
> Nowadays Semantic Versioning is very popular and it is understood by people
> and by automatic tools.
> In many cases we use versions which look like Semantic Versioning (x.y.z) -
> but internally we try to classify it in different ways.
>
> When we connect the plugins version with the Maven version as the major
> version,
> we have difficulty introducing breaking changes for plugins for the same
> Maven version.
> Also we can introduce many misunderstandings which version contains new
> features and which only bug fixes.
>
> Authors of plugins outside Maven core in many cases don't use 3.x as for
> Maven 3 and so on.
>
> One of the propositions can be - use Semantic Versioning as is described
> and put a Maven version in the artifact name of the plugin.
>
> So we can have:
>
> maven4-XXX-plugin - for core plugins
> XXX-maven4-plugin - for external plugins
>
> Additionally Maven 4 will have a new Api which is incompatible with Maven
> 3, when we have the target Maven version in artifact it will be easier to
> transition plugins from 3 to 4 and so on.
>
> Simply in many cases business logic which plugin provides can be extracted
> to a common module and next two modules will provide plugins for specific
> Maven.
> It can help maintain one plugin for many Maven versions.
>
>
> --
> Sławomir Jaranowski



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSSION] Apache Maven plugins versioning

[Romain Manni-Bucau]

Hi,

Think linking maven and maven plugins version does not make sense for most
people since at the end the compat is somehow documented by the
dependencyso using a more common versioning (semver or not) sounds straight
forward.
What would be very bad for me would be a renaming (xxx -> xxx4 for ex) in
the gav or packages (commons style), it has too much impacts for almost no
gain in practise so let's keep it simple and efficient.

Just 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 jeu. 23 mars 2023 à 20:58, Slawomir Jaranowski 
a écrit :

> Hi,
>
> I know that historically plugin versions like 2.x was dedicated to Maven
> 2.x and versions 3.x is for Maven 3.x.
>
> We don't have any written documentation about it (or I can't find it), it
> looks like a traditional agreement.
>
> Nowadays Semantic Versioning is very popular and it is understood by people
> and by automatic tools.
> In many cases we use versions which look like Semantic Versioning (x.y.z) -
> but internally we try to classify it in different ways.
>
> When we connect the plugins version with the Maven version as the major
> version,
> we have difficulty introducing breaking changes for plugins for the same
> Maven version.
> Also we can introduce many misunderstandings which version contains new
> features and which only bug fixes.
>
> Authors of plugins outside Maven core in many cases don't use 3.x as for
> Maven 3 and so on.
>
> One of the propositions can be - use Semantic Versioning as is described
> and put a Maven version in the artifact name of the plugin.
>
> So we can have:
>
> maven4-XXX-plugin - for core plugins
> XXX-maven4-plugin - for external plugins
>
> Additionally Maven 4 will have a new Api which is incompatible with Maven
> 3, when we have the target Maven version in artifact it will be easier to
> transition plugins from 3 to 4 and so on.
>
> Simply in many cases business logic which plugin provides can be extracted
> to a common module and next two modules will provide plugins for specific
> Maven.
> It can help maintain one plugin for many Maven versions.
>
>
> --
> Sławomir Jaranowski
>

[DISCUSSION] Apache Maven plugins versioning

[Slawomir Jaranowski]

Hi,

I know that historically plugin versions like 2.x was dedicated to Maven
2.x and versions 3.x is for Maven 3.x.

We don't have any written documentation about it (or I can't find it), it
looks like a traditional agreement.

Nowadays Semantic Versioning is very popular and it is understood by people
and by automatic tools.
In many cases we use versions which look like Semantic Versioning (x.y.z) -
but internally we try to classify it in different ways.

When we connect the plugins version with the Maven version as the major
version,
we have difficulty introducing breaking changes for plugins for the same
Maven version.
Also we can introduce many misunderstandings which version contains new
features and which only bug fixes.

Authors of plugins outside Maven core in many cases don't use 3.x as for
Maven 3 and so on.

One of the propositions can be - use Semantic Versioning as is described
and put a Maven version in the artifact name of the plugin.

So we can have:

maven4-XXX-plugin - for core plugins
XXX-maven4-plugin - for external plugins

Additionally Maven 4 will have a new Api which is incompatible with Maven
3, when we have the target Maven version in artifact it will be easier to
transition plugins from 3 to 4 and so on.

Simply in many cases business logic which plugin provides can be extracted
to a common module and next two modules will provide plugins for specific
Maven.
It can help maintain one plugin for many Maven versions.


-- 
Sławomir Jaranowski

[GitHub] [maven-site] slachiewicz closed pull request #37: Recommend using Semantic Versioning

[GitBox]

slachiewicz closed pull request #37:
URL: https://github.com/apache/maven-site/pull/37


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site] slachiewicz closed pull request #37: Recommend using Semantic Versioning

[GitBox]

slachiewicz closed pull request #37:
URL: https://github.com/apache/maven-site/pull/37


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

I guess we all agree on that so we just need to write it then?

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. 21 avr. 2021 à 13:18, Gary Gregory  a
écrit :

> Well said Ralph :-)
>
> Gary
>
> On Wed, Apr 21, 2021, 02:26 Ralph Goers 
> wrote:
>
> > FWIW, I prefer that a project (any project, not just Maven) have a
> > documented versioning policy that says something like “We use Semantic
> > Versioning [1]. We don’t skip version numbers for things someone said a
> > future release might contain. We do have guidance that specifies what is
> > guaranteed to be backward compatible and what is not. That guidance is
> …”.
> >
> > That said, a release manager is pretty much always free to do what they
> > choose. It is up to the PMC to accept or reject a release based on
> whatever
> > criteria the PMC has decided upon.
> >
> > In the end though, I am going to support those who are doing the hard
> work.
> >
> > Ralph
> >
> > [1] https://semver.org/
> >
> > > On Apr 20, 2021, at 11:12 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> > >
> > > Well, i'd like we close this topic by an action and not let it die if
> > > possible.
> > > That said, as mentionned originally, what I want we write and publish
> is
> > > what we guarantee.
> > > I tried to write what i'd like to see/would expect as an user but if
> the
> > > agreement is that there will be no guarantee i'm fine with that too -
> > would
> > > be happy to have some help on the wording for such a statement though.
> > > This kind of statement also solves the issue and would close this
> thread
> > > for me.
> > >
> > > I like the idea of Benjamin of listing support companies but I think it
> > is
> > > worth another page maybe (linked from the previous one/history page
> Hervé
> > > mentionned).
> > >
> > > Would this kind of solution work for everybody? To be concrete:
> > >
> > > 1. we write on history page that there is no guarantee of version for a
> > > security fix (Ex: if the fix requires a new feature it will likely not
> > hit
> > > a patch release but a minor one using semver semantic)
> > > 2. we create a support page
> > >
> > > Wdyt?
> > >
> > > 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. 20 avr. 2021 à 20:03, Benjamin Marwell  a
> > > écrit :
> > >
> > >> I tend to agree to Robert, although I find your idea appealing and do
> > >> understand the motivation.
> > >>
> > >> If you look at some Eclipse projects, they also refer you to companies
> > like
> > >> IBM if you want anything beyond [1].
> > >>
> > >> Ben
> > >>
> > >> [1]: e.g.
> > >> https://adoptopenjdk.net/support.html
> > >>
> > >> On Tue, 20 Apr 2021, 19:55 Robert Scholte, 
> > wrote:
> > >>
> > >>> Romain,
> > >>>
> > >>> I still don't like this approach.
> > >>>
> > >>> What you're asking tend to look like contracts and SLA's and as long
> as
> > >>> we're maintaining Maven with a very small group of volunteers and
> > aren't
> > >>> backed full time by some company we shouldn't do this.
> > >>> If there are companies that use Maven and want this kind of
> commitment,
> > >> we
> > >>> need to start a different discussion.
> > >>> E.g. could/should I (or any other Maven developer) start to offer
> Maven
> > >>> Support contracts and under what conditions?
> > >>>
> > >>> Keep in mind that you are the only th

Re: Security/Versioning policy proposal

[Gary Gregory]

Well said Ralph :-)

Gary

On Wed, Apr 21, 2021, 02:26 Ralph Goers  wrote:

> FWIW, I prefer that a project (any project, not just Maven) have a
> documented versioning policy that says something like “We use Semantic
> Versioning [1]. We don’t skip version numbers for things someone said a
> future release might contain. We do have guidance that specifies what is
> guaranteed to be backward compatible and what is not. That guidance is …”.
>
> That said, a release manager is pretty much always free to do what they
> choose. It is up to the PMC to accept or reject a release based on whatever
> criteria the PMC has decided upon.
>
> In the end though, I am going to support those who are doing the hard work.
>
> Ralph
>
> [1] https://semver.org/
>
> > On Apr 20, 2021, at 11:12 AM, Romain Manni-Bucau 
> wrote:
> >
> > Well, i'd like we close this topic by an action and not let it die if
> > possible.
> > That said, as mentionned originally, what I want we write and publish is
> > what we guarantee.
> > I tried to write what i'd like to see/would expect as an user but if the
> > agreement is that there will be no guarantee i'm fine with that too -
> would
> > be happy to have some help on the wording for such a statement though.
> > This kind of statement also solves the issue and would close this thread
> > for me.
> >
> > I like the idea of Benjamin of listing support companies but I think it
> is
> > worth another page maybe (linked from the previous one/history page Hervé
> > mentionned).
> >
> > Would this kind of solution work for everybody? To be concrete:
> >
> > 1. we write on history page that there is no guarantee of version for a
> > security fix (Ex: if the fix requires a new feature it will likely not
> hit
> > a patch release but a minor one using semver semantic)
> > 2. we create a support page
> >
> > Wdyt?
> >
> > 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. 20 avr. 2021 à 20:03, Benjamin Marwell  a
> > écrit :
> >
> >> I tend to agree to Robert, although I find your idea appealing and do
> >> understand the motivation.
> >>
> >> If you look at some Eclipse projects, they also refer you to companies
> like
> >> IBM if you want anything beyond [1].
> >>
> >> Ben
> >>
> >> [1]: e.g.
> >> https://adoptopenjdk.net/support.html
> >>
> >> On Tue, 20 Apr 2021, 19:55 Robert Scholte, 
> wrote:
> >>
> >>> Romain,
> >>>
> >>> I still don't like this approach.
> >>>
> >>> What you're asking tend to look like contracts and SLA's and as long as
> >>> we're maintaining Maven with a very small group of volunteers and
> aren't
> >>> backed full time by some company we shouldn't do this.
> >>> If there are companies that use Maven and want this kind of commitment,
> >> we
> >>> need to start a different discussion.
> >>> E.g. could/should I (or any other Maven developer) start to offer Maven
> >>> Support contracts and under what conditions?
> >>>
> >>> Keep in mind that you are the only that keeps pushing this topic.
> >>> I noticed that it frustrates some and that it they loose their
> motivation
> >>> to work on Maven.
> >>> Please reconsider if it is still worth the discussion or that you can
> >>> solve it for yourself.
> >>>
> >>> thanks,
> >>> Robert
> >>> On 19-4-2021 20:05:53, Romain Manni-Bucau 
> wrote:
> >>> Le lun. 19 avr. 2021 à 17:20, Benjamin Marwell a
> >>> écrit :
> >>>
> >>>>> Do we write 3.6 and 4 are active and maintained branches currently or
> >>>> do we
> >>>>> drop 3.x with first 4.x release?
> >>>>
> >>>> Dropping 3.x with the first 4.x release would not make sense from the
> >>>> point you presented earlier.
> >>>> I'd drop 3.x as soon as we reach 4.1.0.
> >>>>
> >>>
> >>> I can agree but it also means we define what is 4.1.0 and since we
> "jump"
> &

Re: Security/Versioning policy proposal

[Ralph Goers]

FWIW, I prefer that a project (any project, not just Maven) have a documented 
versioning policy that says something like “We use Semantic Versioning [1]. We 
don’t skip version numbers for things someone said a future release might 
contain. We do have guidance that specifies what is guaranteed to be backward 
compatible and what is not. That guidance is …”.

That said, a release manager is pretty much always free to do what they choose. 
It is up to the PMC to accept or reject a release based on whatever criteria 
the PMC has decided upon. 

In the end though, I am going to support those who are doing the hard work.

Ralph

[1] https://semver.org/

> On Apr 20, 2021, at 11:12 AM, Romain Manni-Bucau  
> wrote:
> 
> Well, i'd like we close this topic by an action and not let it die if
> possible.
> That said, as mentionned originally, what I want we write and publish is
> what we guarantee.
> I tried to write what i'd like to see/would expect as an user but if the
> agreement is that there will be no guarantee i'm fine with that too - would
> be happy to have some help on the wording for such a statement though.
> This kind of statement also solves the issue and would close this thread
> for me.
> 
> I like the idea of Benjamin of listing support companies but I think it is
> worth another page maybe (linked from the previous one/history page Hervé
> mentionned).
> 
> Would this kind of solution work for everybody? To be concrete:
> 
> 1. we write on history page that there is no guarantee of version for a
> security fix (Ex: if the fix requires a new feature it will likely not hit
> a patch release but a minor one using semver semantic)
> 2. we create a support page
> 
> Wdyt?
> 
> 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. 20 avr. 2021 à 20:03, Benjamin Marwell  a
> écrit :
> 
>> I tend to agree to Robert, although I find your idea appealing and do
>> understand the motivation.
>> 
>> If you look at some Eclipse projects, they also refer you to companies like
>> IBM if you want anything beyond [1].
>> 
>> Ben
>> 
>> [1]: e.g.
>> https://adoptopenjdk.net/support.html
>> 
>> On Tue, 20 Apr 2021, 19:55 Robert Scholte,  wrote:
>> 
>>> Romain,
>>> 
>>> I still don't like this approach.
>>> 
>>> What you're asking tend to look like contracts and SLA's and as long as
>>> we're maintaining Maven with a very small group of volunteers and aren't
>>> backed full time by some company we shouldn't do this.
>>> If there are companies that use Maven and want this kind of commitment,
>> we
>>> need to start a different discussion.
>>> E.g. could/should I (or any other Maven developer) start to offer Maven
>>> Support contracts and under what conditions?
>>> 
>>> Keep in mind that you are the only that keeps pushing this topic.
>>> I noticed that it frustrates some and that it they loose their motivation
>>> to work on Maven.
>>> Please reconsider if it is still worth the discussion or that you can
>>> solve it for yourself.
>>> 
>>> thanks,
>>> Robert
>>> On 19-4-2021 20:05:53, Romain Manni-Bucau  wrote:
>>> Le lun. 19 avr. 2021 à 17:20, Benjamin Marwell a
>>> écrit :
>>> 
>>>>> Do we write 3.6 and 4 are active and maintained branches currently or
>>>> do we
>>>>> drop 3.x with first 4.x release?
>>>> 
>>>> Dropping 3.x with the first 4.x release would not make sense from the
>>>> point you presented earlier.
>>>> I'd drop 3.x as soon as we reach 4.1.0.
>>>> 
>>> 
>>> I can agree but it also means we define what is 4.1.0 and since we "jump"
>>> versions it will require us to better respect what we plan (I think it is
>>> very good, don't take it wrong).
>>> 
>>> 
>>>> 
>>>>> maintenance branches on demands
>>>> My vote would be to cherry pick security fixes for the previous minor
>>>> version.
>>>> E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current
>>>> latest versions are 4.0.0. and 3.8.1).
>>>> 
>>>> I mean, we can try this for a single release and see if we like it.
>>>

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

> anticipation of version but it is known upfront).
> > Indeed I'm not a fan of such "you will see" policies but it clarifies the
> > point which is my main blocker at the moment at least we can justify our
> > last behavior.
> > This is really the answer I'm after: explicit what we do and continue or
> > make us more rigorous in the future.
> >
> > That said I note the "we can still revert back" point which is surely a
> > very good one so idea can be to write "we will do " and add a banner
> on
> > top saying "experimental policy until " (for example for a year) and
> we
> > can change the policy (and update the deadline) within this duration if
> it
> > does not fit. This would enable us to test and validate the policy with
> an
> > error right and let the user know it upfront.
> >
> > So proposal can be:
> >
> > [Experimental policy until June 2022]
> > 1. We maintain two major releases, ie 3.x and 4.x as of today (no minor
> in
> > particular, just the highest one)
> > 2. We maintain versions and notify the EOL 3 years before it is reached
> (so
> > if we want to EOL v3 in 2025 we will notify users in 2022)
> > 3. We backport and release security fixes (new feature or not) in all
> > maintained branches
> >
> > Wdyt?
> >
> >
> > >
> > > Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau
> > > :
> > > >
> > > > Hi all,
> > > >
> > > > Back on this topic - which prepares v4 releases too btw.
> > > >
> > > > What do we finally write?
> > > >
> > > > That maven will always fix the latest (stable) version and can
> release
> > > > maintenance branches on demands (lazily)?
> > > >
> > > > Do we write 3.6 and 4 are active and maintained branches currently or
> > do
> > > we
> > > > drop 3.x with first 4.x release?
> > > >
> > > > Indeed I'd like the 2 branches option but I am fine with whatever
> > policy
> > > > while written and clear for end users upfront. I'd love we solve that
> > > > before next release if possible cause it always create pointless work
> > due
> > > > to the blurry exchanges on this topic over our website and the
> net/mail
> > > > archives.
> > > >
> > > >
> > > > Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau
> > > a
> > > > écrit :
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Le lun. 5 avr. 2021 à 17:42, Ralph Goers
> > > a
> > > > > écrit :
> > > > >
> > > > >> I don’t understand the point. The very next version of Maven did
> get
> > > the
> > > > >> security fix. Just because the release manager decided to follow a
> > > peculiar
> > > > >> version numbering practice unique to Maven doesn’t mean there is a
> > > problem.
> > > > >>
> > > > >
> > > > > This had been an issue only because the versioning policy of maven
> is
> > > > > undefined.
> > > > > If defined it is perfectly fine for me.
> > > > >
> > > > >
> > > > >>
> > > > >> I don’t know what you mean by random, nor do I know what you mean
> > by a
> > > > >> stability statement. AFAIK Maven has been very stable from the 2.x
> > > versions
> > > > >> through the 3.x versions. In some ways too stable, which is why
> > > introducing
> > > > >> new concepts that have been wanted for years is so hard.
> > > > >>
> > > > >
> > > > > Last statements tend to mean that once 4.x will be there, 3.x will
> be
> > > > > forgotten and no more maintained.
> > > > > Since it is a breaking change and if you picked 3.x today it is a
> big
> > > deal
> > > > > since you have no guarantee you can upgrade without a lot of
> > > investment and
> > > > > get security fixes when needed by just upgrading (and potentially
> > > tuning a
> > > > > bit the conf but not by rewriting the poms for ex).
> > > > >
> > > > > For 2.x -> 3.x time, the 2.x was maintained some years.
> > > > > This is very close to the LTS concept, and this is mainly this kind
> > of
> &g

Re: Security/Versioning policy proposal

[Benjamin Marwell]

gt; > > Do we write 3.6 and 4 are active and maintained branches currently or
> do
> > we
> > > drop 3.x with first 4.x release?
> > >
> > > Indeed I'd like the 2 branches option but I am fine with whatever
> policy
> > > while written and clear for end users upfront. I'd love we solve that
> > > before next release if possible cause it always create pointless work
> due
> > > to the blurry exchanges on this topic over our website and the net/mail
> > > archives.
> > >
> > >
> > > Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau
> > a
> > > écrit :
> > >
> > > >
> > > >
> > > >
> > > > Le lun. 5 avr. 2021 à 17:42, Ralph Goers
> > a
> > > > écrit :
> > > >
> > > >> I don’t understand the point. The very next version of Maven did get
> > the
> > > >> security fix. Just because the release manager decided to follow a
> > peculiar
> > > >> version numbering practice unique to Maven doesn’t mean there is a
> > problem.
> > > >>
> > > >
> > > > This had been an issue only because the versioning policy of maven is
> > > > undefined.
> > > > If defined it is perfectly fine for me.
> > > >
> > > >
> > > >>
> > > >> I don’t know what you mean by random, nor do I know what you mean
> by a
> > > >> stability statement. AFAIK Maven has been very stable from the 2.x
> > versions
> > > >> through the 3.x versions. In some ways too stable, which is why
> > introducing
> > > >> new concepts that have been wanted for years is so hard.
> > > >>
> > > >
> > > > Last statements tend to mean that once 4.x will be there, 3.x will be
> > > > forgotten and no more maintained.
> > > > Since it is a breaking change and if you picked 3.x today it is a big
> > deal
> > > > since you have no guarantee you can upgrade without a lot of
> > investment and
> > > > get security fixes when needed by just upgrading (and potentially
> > tuning a
> > > > bit the conf but not by rewriting the poms for ex).
> > > >
> > > > For 2.x -> 3.x time, the 2.x was maintained some years.
> > > > This is very close to the LTS concept, and this is mainly this kind
> of
> > > > statement I'm trying to get to let projects plan properly and not
> have
> > > > maven on their road too easily.
> > > > If properly defined it will not impact much maven dev but can save a
> > lot
> > > > of time for enterprises and enable them to properly setup their
> > projects in
> > > > time.
> > > >
> > > > So overall the definition points are still the same:
> > > >
> > > > 1. which versions are maintained (ie can get security fixes - new
> > features
> > > > are not required to be in the box here)
> > > > 2. for how long
> > > > 3. what does mean version (major.minor.*, major.* for ex) in 1.
> > > >
> > > > "3.x will be supported for 3 more years when 4.x is out and
> maintained
> > > > major versions are guaranteed to get security fixes" is a kind of
> > statement
> > > > which solves that - we can also use N=current and N+1 in the
> statement
> > to
> > > > not stick it to 3 and 4.
> > > > "4.x is the current released branch, other branch will never be
> > released
> > > > anymore" does not work for me for example IMHO (but we can put it on
> > vote
> > > > if that's the community desire).
> > > >
> > > >
> > > >>
> > > >> FWIW, my employer’s repository manager still uses http since it is
> > behind
> > > >> a VPN. After trying 3.8.1 I found I had to specify mirrors for all
> the
> > > >> repos even though they are not defined in pom’s. Apparently the fix
> > also
> > > >> affects repositories defined in settings.xml.
> > > >>
> > > >
> > > > Yes because it is a mirror and wildcard one.
> > > > Using a custom global settings - to override default one - is a
> > solution
> > > > if you know all http repositories you want to force to be blocked
> (can
> > be
> > > > hard since you never know all of them by definition and mirroring
> does
> > not
> > > > suppo

Re: Security/Versioning policy proposal

[Robert Scholte]

Romain,

I still don't like this approach. 

What you're asking tend to look like contracts and SLA's and as long as we're 
maintaining Maven with a very small group of volunteers and aren't backed full 
time by some company we shouldn't do this.
If there are companies that use Maven and want this kind of commitment, we need 
to start a different discussion.
E.g. could/should I (or any other Maven developer) start to offer Maven Support 
contracts and under what conditions?

Keep in mind that you are the only that keeps pushing this topic.
I noticed that it frustrates some and that it they loose their motivation to 
work on Maven.
Please reconsider if it is still worth the discussion or that you can solve it 
for yourself.

thanks,
Robert
On 19-4-2021 20:05:53, Romain Manni-Bucau  wrote:
Le lun. 19 avr. 2021 à 17:20, Benjamin Marwell a
écrit :

> > Do we write 3.6 and 4 are active and maintained branches currently or
> do we
> > drop 3.x with first 4.x release?
>
> Dropping 3.x with the first 4.x release would not make sense from the
> point you presented earlier.
> I'd drop 3.x as soon as we reach 4.1.0.
>

I can agree but it also means we define what is 4.1.0 and since we "jump"
versions it will require us to better respect what we plan (I think it is
very good, don't take it wrong).


>
> > maintenance branches on demands
> My vote would be to cherry pick security fixes for the previous minor
> version.
> E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current
> latest versions are 4.0.0. and 3.8.1).
>
> I mean, we can try this for a single release and see if we like it.
> If not, we can still drop this again and revert back to "on demand"
> maintenance branches.
>
> Backporting features does not make sense (imo) how maven treats releases.
>

I think it is the whole point: what when we fix a security issue by a new
feature -> "does not make sense" (quoting your words but that's what was
the outcome for 3.8.1) and it is exactly the issue I face and I want we
fix: no predictability on stable maven versions with a minimal maintenance
"guaranteed" (no security issue opened in CVE databases).
So I think we either write we backport the security fixes in last 2
maintained branches with some duration (we can align on java LTS duration
for example which should be close to our major breaking changes) or we
write we don't care and only maintain the last release branch and it is the
only one guaranteed to get fixes (which kind of means there will be no
anticipation of version but it is known upfront).
Indeed I'm not a fan of such "you will see" policies but it clarifies the
point which is my main blocker at the moment at least we can justify our
last behavior.
This is really the answer I'm after: explicit what we do and continue or
make us more rigorous in the future.

That said I note the "we can still revert back" point which is surely a
very good one so idea can be to write "we will do " and add a banner on
top saying "experimental policy until " (for example for a year) and we
can change the policy (and update the deadline) within this duration if it
does not fit. This would enable us to test and validate the policy with an
error right and let the user know it upfront.

So proposal can be:

[Experimental policy until June 2022]
1. We maintain two major releases, ie 3.x and 4.x as of today (no minor in
particular, just the highest one)
2. We maintain versions and notify the EOL 3 years before it is reached (so
if we want to EOL v3 in 2025 we will notify users in 2022)
3. We backport and release security fixes (new feature or not) in all
maintained branches

Wdyt?


>
> Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau
> :
> >
> > Hi all,
> >
> > Back on this topic - which prepares v4 releases too btw.
> >
> > What do we finally write?
> >
> > That maven will always fix the latest (stable) version and can release
> > maintenance branches on demands (lazily)?
> >
> > Do we write 3.6 and 4 are active and maintained branches currently or do
> we
> > drop 3.x with first 4.x release?
> >
> > Indeed I'd like the 2 branches option but I am fine with whatever policy
> > while written and clear for end users upfront. I'd love we solve that
> > before next release if possible cause it always create pointless work due
> > to the blurry exchanges on this topic over our website and the net/mail
> > archives.
> >
> >
> > Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau
> a
> > écrit :
> >
> > >
> > >
> > >
> > > Le lun. 5 avr. 2021 à 17:42, Ralph Goers
> a
> > > écrit :
> > >
> > >> I don’t understand

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

Le lun. 19 avr. 2021 à 17:20, Benjamin Marwell  a
écrit :

> >  Do we write 3.6 and 4 are active and maintained branches currently or
> do we
> > drop 3.x with first 4.x release?
>
> Dropping 3.x with the first 4.x release would not make sense from the
> point you presented earlier.
> I'd drop 3.x as soon as we reach 4.1.0.
>

I can agree but it also means we define what is 4.1.0 and since we "jump"
versions it will require us to better respect what we plan (I think it is
very good, don't take it wrong).


>
> > maintenance branches on demands
> My vote would be to cherry pick security fixes for the previous minor
> version.
> E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current
> latest versions are 4.0.0. and 3.8.1).
>
> I mean, we can try this for a single release and see if we like it.
> If not, we can still drop this again and revert back to "on demand"
> maintenance branches.
>
> Backporting features does not make sense (imo) how maven treats releases.
>

I think it is the whole point: what when we fix a security issue by a new
feature -> "does not make sense" (quoting your words but that's what was
the outcome for 3.8.1) and it is exactly the issue I face and I want we
fix: no predictability on stable maven versions with a minimal maintenance
"guaranteed" (no security issue opened in CVE databases).
So I think we either write we backport the security fixes in last 2
maintained branches with some duration (we can align on java LTS duration
for example which should be close to our major breaking changes) or we
write we don't care and only maintain the last release branch and it is the
only one guaranteed to get fixes (which kind of means there will be no
anticipation of version but it is known upfront).
Indeed I'm not a fan of such "you will see" policies but it clarifies the
point which is my main blocker at the moment at least we can justify our
last behavior.
This is really the answer I'm after: explicit what we do and continue or
make us more rigorous in the future.

That said I note the "we can still revert back" point which is surely a
very good one so idea can be to write "we will do " and add a banner on
top saying "experimental policy until " (for example for a year) and we
can change the policy (and update the deadline) within this duration if it
does not fit. This would enable us to test and validate the policy with an
error right and let the user know it upfront.

So proposal can be:

[Experimental policy until June 2022]
1. We maintain two major releases, ie 3.x and 4.x as of today (no minor in
particular, just the highest one)
2. We maintain versions and notify the EOL 3 years before it is reached (so
if we want to EOL v3 in 2025 we will notify users in 2022)
3. We backport and release security fixes (new feature or not) in all
maintained branches

Wdyt?


>
> Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau
> :
> >
> > Hi all,
> >
> > Back on this topic - which prepares v4 releases too btw.
> >
> > What do we finally write?
> >
> > That maven will always fix the latest (stable) version and can release
> > maintenance branches on demands (lazily)?
> >
> > Do we write 3.6 and 4 are active and maintained branches currently or do
> we
> > drop 3.x with first 4.x release?
> >
> > Indeed I'd like the 2 branches option but I am fine with whatever policy
> > while written and clear for end users upfront. I'd love we solve that
> > before next release if possible cause it always create pointless work due
> > to the blurry exchanges on this topic over our website and the net/mail
> > archives.
> >
> >
> > Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau 
> a
> > écrit :
> >
> > >
> > >
> > >
> > > Le lun. 5 avr. 2021 à 17:42, Ralph Goers 
> a
> > > écrit :
> > >
> > >> I don’t understand the point. The very next version of Maven did get
> the
> > >> security fix. Just because the release manager decided to follow a
> peculiar
> > >> version numbering practice unique to Maven doesn’t mean there is a
> problem.
> > >>
> > >
> > > This had been an issue only because the versioning policy of maven is
> > > undefined.
> > > If defined it is perfectly fine for me.
> > >
> > >
> > >>
> > >> I don’t know what you mean by random, nor do I know what you mean by a
> > >> stability statement. AFAIK Maven has been very stable from the 2.x
> versions
> > >> through the 3.x versions. In some ways too stable, which is why
> introducing
> > &

Re: Security/Versioning policy proposal

[Benjamin Marwell]

>  Do we write 3.6 and 4 are active and maintained branches currently or do we
> drop 3.x with first 4.x release?

Dropping 3.x with the first 4.x release would not make sense from the
point you presented earlier.
I'd drop 3.x as soon as we reach 4.1.0.

> maintenance branches on demands
My vote would be to cherry pick security fixes for the previous minor version.
E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current
latest versions are 4.0.0. and 3.8.1).

I mean, we can try this for a single release and see if we like it.
If not, we can still drop this again and revert back to "on demand"
maintenance branches.

Backporting features does not make sense (imo) how maven treats releases.

Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau
:
>
> Hi all,
>
> Back on this topic - which prepares v4 releases too btw.
>
> What do we finally write?
>
> That maven will always fix the latest (stable) version and can release
> maintenance branches on demands (lazily)?
>
> Do we write 3.6 and 4 are active and maintained branches currently or do we
> drop 3.x with first 4.x release?
>
> Indeed I'd like the 2 branches option but I am fine with whatever policy
> while written and clear for end users upfront. I'd love we solve that
> before next release if possible cause it always create pointless work due
> to the blurry exchanges on this topic over our website and the net/mail
> archives.
>
>
> Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau  a
> écrit :
>
> >
> >
> >
> > Le lun. 5 avr. 2021 à 17:42, Ralph Goers  a
> > écrit :
> >
> >> I don’t understand the point. The very next version of Maven did get the
> >> security fix. Just because the release manager decided to follow a peculiar
> >> version numbering practice unique to Maven doesn’t mean there is a problem.
> >>
> >
> > This had been an issue only because the versioning policy of maven is
> > undefined.
> > If defined it is perfectly fine for me.
> >
> >
> >>
> >> I don’t know what you mean by random, nor do I know what you mean by a
> >> stability statement. AFAIK Maven has been very stable from the 2.x versions
> >> through the 3.x versions. In some ways too stable, which is why introducing
> >> new concepts that have been wanted for years is so hard.
> >>
> >
> > Last statements tend to mean that once 4.x will be there, 3.x will be
> > forgotten and no more maintained.
> > Since it is a breaking change and if you picked 3.x today it is a big deal
> > since you have no guarantee you can upgrade without a lot of investment and
> > get security fixes when needed by just upgrading (and potentially tuning a
> > bit the conf but not by rewriting the poms for ex).
> >
> > For 2.x -> 3.x time, the 2.x was maintained some years.
> > This is very close to the LTS concept, and this is mainly this kind of
> > statement I'm trying to get to let projects plan properly and not have
> > maven on their road too easily.
> > If properly defined it will not impact much maven dev but can save a lot
> > of time for enterprises and enable them to properly setup their projects in
> > time.
> >
> > So overall the definition points are still the same:
> >
> > 1. which versions are maintained (ie can get security fixes - new features
> > are not required to be in the box here)
> > 2. for how long
> > 3. what does mean version (major.minor.*, major.* for ex) in 1.
> >
> > "3.x will be supported for 3 more years when 4.x is out and maintained
> > major versions are guaranteed to get security fixes" is a kind of statement
> > which solves that - we can also use N=current and N+1 in the statement to
> > not stick it to 3 and 4.
> > "4.x is the current released branch, other branch will never be released
> > anymore" does not work for me for example IMHO (but we can put it on vote
> > if that's the community desire).
> >
> >
> >>
> >> FWIW, my employer’s repository manager still uses http since it is behind
> >> a VPN. After trying 3.8.1 I found I had to specify mirrors for all the
> >> repos even though they are not defined in pom’s. Apparently the fix also
> >> affects repositories defined in settings.xml.
> >>
> >
> > Yes because it is a mirror and wildcard one.
> > Using a custom global settings - to override default one - is a solution
> > if you know all http repositories you want to force to be blocked (can be
> > hard since you never know all of them by definition and mirroring does not
> > support custom pat

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

Hi all,

Back on this topic - which prepares v4 releases too btw.

What do we finally write?

That maven will always fix the latest (stable) version and can release
maintenance branches on demands (lazily)?

Do we write 3.6 and 4 are active and maintained branches currently or do we
drop 3.x with first 4.x release?

Indeed I'd like the 2 branches option but I am fine with whatever policy
while written and clear for end users upfront. I'd love we solve that
before next release if possible cause it always create pointless work due
to the blurry exchanges on this topic over our website and the net/mail
archives.


Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau  a
écrit :

>
>
>
> Le lun. 5 avr. 2021 à 17:42, Ralph Goers  a
> écrit :
>
>> I don’t understand the point. The very next version of Maven did get the
>> security fix. Just because the release manager decided to follow a peculiar
>> version numbering practice unique to Maven doesn’t mean there is a problem.
>>
>
> This had been an issue only because the versioning policy of maven is
> undefined.
> If defined it is perfectly fine for me.
>
>
>>
>> I don’t know what you mean by random, nor do I know what you mean by a
>> stability statement. AFAIK Maven has been very stable from the 2.x versions
>> through the 3.x versions. In some ways too stable, which is why introducing
>> new concepts that have been wanted for years is so hard.
>>
>
> Last statements tend to mean that once 4.x will be there, 3.x will be
> forgotten and no more maintained.
> Since it is a breaking change and if you picked 3.x today it is a big deal
> since you have no guarantee you can upgrade without a lot of investment and
> get security fixes when needed by just upgrading (and potentially tuning a
> bit the conf but not by rewriting the poms for ex).
>
> For 2.x -> 3.x time, the 2.x was maintained some years.
> This is very close to the LTS concept, and this is mainly this kind of
> statement I'm trying to get to let projects plan properly and not have
> maven on their road too easily.
> If properly defined it will not impact much maven dev but can save a lot
> of time for enterprises and enable them to properly setup their projects in
> time.
>
> So overall the definition points are still the same:
>
> 1. which versions are maintained (ie can get security fixes - new features
> are not required to be in the box here)
> 2. for how long
> 3. what does mean version (major.minor.*, major.* for ex) in 1.
>
> "3.x will be supported for 3 more years when 4.x is out and maintained
> major versions are guaranteed to get security fixes" is a kind of statement
> which solves that - we can also use N=current and N+1 in the statement to
> not stick it to 3 and 4.
> "4.x is the current released branch, other branch will never be released
> anymore" does not work for me for example IMHO (but we can put it on vote
> if that's the community desire).
>
>
>>
>> FWIW, my employer’s repository manager still uses http since it is behind
>> a VPN. After trying 3.8.1 I found I had to specify mirrors for all the
>> repos even though they are not defined in pom’s. Apparently the fix also
>> affects repositories defined in settings.xml.
>>
>
> Yes because it is a mirror and wildcard one.
> Using a custom global settings - to override default one - is a solution
> if you know all http repositories you want to force to be blocked (can be
> hard since you never know all of them by definition and mirroring does not
> support custom patterns but can be a quick workaround to upgrade without
> blocking builds).
>
>
>>
>> Ralph
>>
>> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau 
>> wrote:
>> >
>> > Hmm, general/common asf way of doing is to move forward until users ask
>> > (and if so any branch is patched while a pr is done).
>> > If maven does not follow that practise it cant say "last version will
>> get
>> > the security fix" too because it means "we dont care of users, to get
>> the
>> > cve fix you will have to rewrite your build".
>> > So at least a major stability statement is required IMO with some lts
>> > statement and eol on majors.
>> > Without that using maven sounds random for projects, no?
>> >
>> > Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels  a
>> > écrit :
>> >
>> >> I agree, maven does not need to concern itself with branches as long
>> as it
>> >> stays fairly forward drop-in compatible.
>> >>
>> >> Having said that, things like changing the policy for handling http

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

Le lun. 5 avr. 2021 à 17:42, Ralph Goers  a
écrit :

> I don’t understand the point. The very next version of Maven did get the
> security fix. Just because the release manager decided to follow a peculiar
> version numbering practice unique to Maven doesn’t mean there is a problem.
>

This had been an issue only because the versioning policy of maven is
undefined.
If defined it is perfectly fine for me.


>
> I don’t know what you mean by random, nor do I know what you mean by a
> stability statement. AFAIK Maven has been very stable from the 2.x versions
> through the 3.x versions. In some ways too stable, which is why introducing
> new concepts that have been wanted for years is so hard.
>

Last statements tend to mean that once 4.x will be there, 3.x will be
forgotten and no more maintained.
Since it is a breaking change and if you picked 3.x today it is a big deal
since you have no guarantee you can upgrade without a lot of investment and
get security fixes when needed by just upgrading (and potentially tuning a
bit the conf but not by rewriting the poms for ex).

For 2.x -> 3.x time, the 2.x was maintained some years.
This is very close to the LTS concept, and this is mainly this kind of
statement I'm trying to get to let projects plan properly and not have
maven on their road too easily.
If properly defined it will not impact much maven dev but can save a lot of
time for enterprises and enable them to properly setup their projects in
time.

So overall the definition points are still the same:

1. which versions are maintained (ie can get security fixes - new features
are not required to be in the box here)
2. for how long
3. what does mean version (major.minor.*, major.* for ex) in 1.

"3.x will be supported for 3 more years when 4.x is out and maintained
major versions are guaranteed to get security fixes" is a kind of statement
which solves that - we can also use N=current and N+1 in the statement to
not stick it to 3 and 4.
"4.x is the current released branch, other branch will never be released
anymore" does not work for me for example IMHO (but we can put it on vote
if that's the community desire).


>
> FWIW, my employer’s repository manager still uses http since it is behind
> a VPN. After trying 3.8.1 I found I had to specify mirrors for all the
> repos even though they are not defined in pom’s. Apparently the fix also
> affects repositories defined in settings.xml.
>

Yes because it is a mirror and wildcard one.
Using a custom global settings - to override default one - is a solution if
you know all http repositories you want to force to be blocked (can be hard
since you never know all of them by definition and mirroring does not
support custom patterns but can be a quick workaround to upgrade without
blocking builds).


>
> Ralph
>
> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau 
> wrote:
> >
> > Hmm, general/common asf way of doing is to move forward until users ask
> > (and if so any branch is patched while a pr is done).
> > If maven does not follow that practise it cant say "last version will get
> > the security fix" too because it means "we dont care of users, to get the
> > cve fix you will have to rewrite your build".
> > So at least a major stability statement is required IMO with some lts
> > statement and eol on majors.
> > Without that using maven sounds random for projects, no?
> >
> > Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels  a
> > écrit :
> >
> >> I agree, maven does not need to concern itself with branches as long as
> it
> >> stays fairly forward drop-in compatible.
> >>
> >> Having said that, things like changing the policy for handling http
> might
> >> not be that drop-in, but on the other hand it’s just a config option and
> >> does not require complicated (plugin) dependency updates.
> >>
> >> I do wonder if the version number should better reflect such
> incompatible
> >> requirement changes. (And if somebody really wants to provide security
> >> fixes for those incompatible older branches why not, but I don’t think
> you
> >> can require them from a project which does not offer them by themself).
> >>
> >>
> >> --
> >> http://bernd.eckenfels.net
> >> 
> >> Von: Ralph Goers 
> >> Gesendet: Sunday, April 4, 2021 9:55:50 PM
> >> An: Maven Developers List 
> >> Betreff: Re: Security/Versioning policy proposal
> >>
> >> More than likely you will get whatever the next version number happens
> to
> >> be. I can’t think of a case where Maven needed to go back and patch a
> prior
> >> release.  That could happen ho

Re: Security/Versioning policy proposal

[Ralph Goers]

I don’t understand the point. The very next version of Maven did get the 
security fix. Just because the release manager decided to follow a peculiar 
version numbering practice unique to Maven doesn’t mean there is a problem.

I don’t know what you mean by random, nor do I know what you mean by a 
stability statement. AFAIK Maven has been very stable from the 2.x versions 
through the 3.x versions. In some ways too stable, which is why introducing new 
concepts that have been wanted for years is so hard.

FWIW, my employer’s repository manager still uses http since it is behind a 
VPN. After trying 3.8.1 I found I had to specify mirrors for all the repos even 
though they are not defined in pom’s. Apparently the fix also affects 
repositories defined in settings.xml.

Ralph

> On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau  wrote:
> 
> Hmm, general/common asf way of doing is to move forward until users ask
> (and if so any branch is patched while a pr is done).
> If maven does not follow that practise it cant say "last version will get
> the security fix" too because it means "we dont care of users, to get the
> cve fix you will have to rewrite your build".
> So at least a major stability statement is required IMO with some lts
> statement and eol on majors.
> Without that using maven sounds random for projects, no?
> 
> Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels  a
> écrit :
> 
>> I agree, maven does not need to concern itself with branches as long as it
>> stays fairly forward drop-in compatible.
>> 
>> Having said that, things like changing the policy for handling http might
>> not be that drop-in, but on the other hand it’s just a config option and
>> does not require complicated (plugin) dependency updates.
>> 
>> I do wonder if the version number should better reflect such incompatible
>> requirement changes. (And if somebody really wants to provide security
>> fixes for those incompatible older branches why not, but I don’t think you
>> can require them from a project which does not offer them by themself).
>> 
>> 
>> --
>> http://bernd.eckenfels.net
>> ____
>> Von: Ralph Goers 
>> Gesendet: Sunday, April 4, 2021 9:55:50 PM
>> An: Maven Developers List 
>> Betreff: Re: Security/Versioning policy proposal
>> 
>> More than likely you will get whatever the next version number happens to
>> be. I can’t think of a case where Maven needed to go back and patch a prior
>> release.  That could happen however, if Maven was modified to require Java
>> 11 to run and a security fix had to be applied to the last version
>> supporting Java 8.
>> 
>> Ralph
>> 
>>> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau 
>> wrote:
>>> 
>>> Le dim. 4 avr. 2021 à 14:10, Robert Scholte  a
>> écrit :
>>> 
>>>> To me all releases can contain security fixes.
>>>> Depending on the risk of the CVE we can decide to do a release with only
>>>> those fixes (see Maven 3.0.5 and 3.8.1)
>>>> 
>>> 
>>> I get that but it does not help users to pick versions and to get any
>>> stability in their build - which is the goal of this thread.
>>> Since you rejected a 3.6.4 for last CVE hitting us I have to admit I
>> have a
>>> hard time to formalize it.
>>> Best I come up is "we'll do what we want" which is hopefully just a
>>> complete misinterpretation of what you mean but hope shows how clueless I
>>> am with such a statement at the moment.
>>> Can you try to refine it please?
>>> 
>>> Concretely, today I'm starting with a 3.8.1, what am I expecting to use
>> in
>>> 5 years for this project trying to get security fixes and being stable
>> (ie
>>> 4.x is assumed excluded?)?
>>> 
>>> 
>>>> 
>>>> Robert
>>>> 
>>>> On 4-4-2021 12:14:39, Romain Manni-Bucau  wrote:
>>>> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit :
>>>> 
>>>>> I doubt we can or should make any promises, only intentions.
>>>>> If we would have it, I wonder if it cover our choice to skip 3.7.0.
>>>>> To me we need to keep that flexibility.
>>>>> 
>>>>> I want to reverse the approach: what could users expect as differences
>>>>> between version x and y.
>>>>> 
>>>>> For Maven shouldn't be more complex than:
>>>>> bugfix release-change should be safe "just replace" release with
>> bugfixes
>>>>> and internal improvements.
>

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

Hmm, general/common asf way of doing is to move forward until users ask
(and if so any branch is patched while a pr is done).
If maven does not follow that practise it cant say "last version will get
the security fix" too because it means "we dont care of users, to get the
cve fix you will have to rewrite your build".
So at least a major stability statement is required IMO with some lts
statement and eol on majors.
Without that using maven sounds random for projects, no?

Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels  a
écrit :

> I agree, maven does not need to concern itself with branches as long as it
> stays fairly forward drop-in compatible.
>
> Having said that, things like changing the policy for handling http might
> not be that drop-in, but on the other hand it’s just a config option and
> does not require complicated (plugin) dependency updates.
>
> I do wonder if the version number should better reflect such incompatible
> requirement changes. (And if somebody really wants to provide security
> fixes for those incompatible older branches why not, but I don’t think you
> can require them from a project which does not offer them by themself).
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Ralph Goers 
> Gesendet: Sunday, April 4, 2021 9:55:50 PM
> An: Maven Developers List 
> Betreff: Re: Security/Versioning policy proposal
>
> More than likely you will get whatever the next version number happens to
> be. I can’t think of a case where Maven needed to go back and patch a prior
> release.  That could happen however, if Maven was modified to require Java
> 11 to run and a security fix had to be applied to the last version
> supporting Java 8.
>
> Ralph
>
> > On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau 
> wrote:
> >
> > Le dim. 4 avr. 2021 à 14:10, Robert Scholte  a
> écrit :
> >
> >> To me all releases can contain security fixes.
> >> Depending on the risk of the CVE we can decide to do a release with only
> >> those fixes (see Maven 3.0.5 and 3.8.1)
> >>
> >
> > I get that but it does not help users to pick versions and to get any
> > stability in their build - which is the goal of this thread.
> > Since you rejected a 3.6.4 for last CVE hitting us I have to admit I
> have a
> > hard time to formalize it.
> > Best I come up is "we'll do what we want" which is hopefully just a
> > complete misinterpretation of what you mean but hope shows how clueless I
> > am with such a statement at the moment.
> > Can you try to refine it please?
> >
> > Concretely, today I'm starting with a 3.8.1, what am I expecting to use
> in
> > 5 years for this project trying to get security fixes and being stable
> (ie
> > 4.x is assumed excluded?)?
> >
> >
> >>
> >> Robert
> >>
> >> On 4-4-2021 12:14:39, Romain Manni-Bucau  wrote:
> >> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit :
> >>
> >>> I doubt we can or should make any promises, only intentions.
> >>> If we would have it, I wonder if it cover our choice to skip 3.7.0.
> >>> To me we need to keep that flexibility.
> >>>
> >>> I want to reverse the approach: what could users expect as differences
> >>> between version x and y.
> >>>
> >>> For Maven shouldn't be more complex than:
> >>> bugfix release-change should be safe "just replace" release with
> bugfixes
> >>> and internal improvements.
> >>> minor release-change should represent relevant new features or (as we
> saw
> >>> for 3.8.x) possible breaking builds that can be fixed with
> configuration.
> >>> major release-change represents changes to the architecture that might
> >>> change the behavior.
> >>> as far as I know this defends all Maven releases up until now.
> >>>
> >>
> >> Does not cover the last release - and is actually the issue I'm
> suffering
> >> from right now and why i'd like we cover this case: security fixes. As
> of
> >> today it is a mix between patch (bugfix) and minor lines AFAIK but I'd
> like
> >> we explicit it (even just saying on each line "can include bugfixes").
> >> Said differently: the reverse approach you mention only cover the
> feature
> >> evolution but not the most important for versioning policy: the security
> >> policy which is the one which hurt right now.
> >> As an user, I want to be able to anticipate the versions i can need
> staying
> >> as much as possible on a stable v

Re: Security/Versioning policy proposal

[Bernd Eckenfels]

I agree, maven does not need to concern itself with branches as long as it 
stays fairly forward drop-in compatible.

Having said that, things like changing the policy for handling http might not 
be that drop-in, but on the other hand it’s just a config option and does not 
require complicated (plugin) dependency updates.

I do wonder if the version number should better reflect such incompatible 
requirement changes. (And if somebody really wants to provide security fixes 
for those incompatible older branches why not, but I don’t think you can 
require them from a project which does not offer them by themself).


--
http://bernd.eckenfels.net

Von: Ralph Goers 
Gesendet: Sunday, April 4, 2021 9:55:50 PM
An: Maven Developers List 
Betreff: Re: Security/Versioning policy proposal

More than likely you will get whatever the next version number happens to be. I 
can’t think of a case where Maven needed to go back and patch a prior release.  
That could happen however, if Maven was modified to require Java 11 to run and 
a security fix had to be applied to the last version supporting Java 8.

Ralph

> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau  wrote:
>
> Le dim. 4 avr. 2021 à 14:10, Robert Scholte  a écrit :
>
>> To me all releases can contain security fixes.
>> Depending on the risk of the CVE we can decide to do a release with only
>> those fixes (see Maven 3.0.5 and 3.8.1)
>>
>
> I get that but it does not help users to pick versions and to get any
> stability in their build - which is the goal of this thread.
> Since you rejected a 3.6.4 for last CVE hitting us I have to admit I have a
> hard time to formalize it.
> Best I come up is "we'll do what we want" which is hopefully just a
> complete misinterpretation of what you mean but hope shows how clueless I
> am with such a statement at the moment.
> Can you try to refine it please?
>
> Concretely, today I'm starting with a 3.8.1, what am I expecting to use in
> 5 years for this project trying to get security fixes and being stable (ie
> 4.x is assumed excluded?)?
>
>
>>
>> Robert
>>
>> On 4-4-2021 12:14:39, Romain Manni-Bucau  wrote:
>> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit :
>>
>>> I doubt we can or should make any promises, only intentions.
>>> If we would have it, I wonder if it cover our choice to skip 3.7.0.
>>> To me we need to keep that flexibility.
>>>
>>> I want to reverse the approach: what could users expect as differences
>>> between version x and y.
>>>
>>> For Maven shouldn't be more complex than:
>>> bugfix release-change should be safe "just replace" release with bugfixes
>>> and internal improvements.
>>> minor release-change should represent relevant new features or (as we saw
>>> for 3.8.x) possible breaking builds that can be fixed with configuration.
>>> major release-change represents changes to the architecture that might
>>> change the behavior.
>>> as far as I know this defends all Maven releases up until now.
>>>
>>
>> Does not cover the last release - and is actually the issue I'm suffering
>> from right now and why i'd like we cover this case: security fixes. As of
>> today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like
>> we explicit it (even just saying on each line "can include bugfixes").
>> Said differently: the reverse approach you mention only cover the feature
>> evolution but not the most important for versioning policy: the security
>> policy which is the one which hurt right now.
>> As an user, I want to be able to anticipate the versions i can need staying
>> as much as possible on a stable version (original version) but upgrading to
>> get security fixes.
>> If it is fine for you to mention lines 1 and 2 can include security fixes
>> i'd be to add this paragraph on the history page maybe?
>>
>> wdyt?
>>
>>
>>>
>>> In case of plugins: the major represents the minimal required version of
>>> Maven.
>>>
>>> Robert
>>> On 4-4-2021 11:28:30, Romain Manni-Bucau wrote:
>>> Hi Elliotte,
>>>
>>> My goal is to write what we can promise and users can rely on to work.
>>> If we can only promise any major release will get all security fixes
>>> whatever are the minor/patch versions, be it.
>>> I just want what we do to be explicit.
>>>
>>> Hervé proposed to reference history page of website, it can be a good
>> start
>>> with one or two more sentences to solve that.
>>>
>>> Le sam. 3 avr. 2021 à 23:50, Elliotte 

Re: Security/Versioning policy proposal

[Ralph Goers]

More than likely you will get whatever the next version number happens to be. I 
can’t think of a case where Maven needed to go back and patch a prior release.  
That could happen however, if Maven was modified to require Java 11 to run and 
a security fix had to be applied to the last version supporting Java 8. 

Ralph

> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau  wrote:
> 
> Le dim. 4 avr. 2021 à 14:10, Robert Scholte  a écrit :
> 
>> To me all releases can contain security fixes.
>> Depending on the risk of the CVE we can decide to do a release with only
>> those fixes (see Maven 3.0.5 and 3.8.1)
>> 
> 
> I get that but it does not help users to pick versions and to get any
> stability in their build - which is the goal of this thread.
> Since you rejected a 3.6.4 for last CVE hitting us I have to admit I have a
> hard time to formalize it.
> Best I come up is "we'll do what we want" which is hopefully just a
> complete misinterpretation of what you mean but hope shows how clueless I
> am with such a statement at the moment.
> Can you try to refine it please?
> 
> Concretely, today I'm starting with a 3.8.1, what am I expecting to use in
> 5 years for this project trying to get security fixes and being stable (ie
> 4.x is assumed excluded?)?
> 
> 
>> 
>> Robert
>> 
>> On 4-4-2021 12:14:39, Romain Manni-Bucau  wrote:
>> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit :
>> 
>>> I doubt we can or should make any promises, only intentions.
>>> If we would have it, I wonder if it cover our choice to skip 3.7.0.
>>> To me we need to keep that flexibility.
>>> 
>>> I want to reverse the approach: what could users expect as differences
>>> between version x and y.
>>> 
>>> For Maven shouldn't be more complex than:
>>> bugfix release-change should be safe "just replace" release with bugfixes
>>> and internal improvements.
>>> minor release-change should represent relevant new features or (as we saw
>>> for 3.8.x) possible breaking builds that can be fixed with configuration.
>>> major release-change represents changes to the architecture that might
>>> change the behavior.
>>> as far as I know this defends all Maven releases up until now.
>>> 
>> 
>> Does not cover the last release - and is actually the issue I'm suffering
>> from right now and why i'd like we cover this case: security fixes. As of
>> today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like
>> we explicit it (even just saying on each line "can include bugfixes").
>> Said differently: the reverse approach you mention only cover the feature
>> evolution but not the most important for versioning policy: the security
>> policy which is the one which hurt right now.
>> As an user, I want to be able to anticipate the versions i can need staying
>> as much as possible on a stable version (original version) but upgrading to
>> get security fixes.
>> If it is fine for you to mention lines 1 and 2 can include security fixes
>> i'd be to add this paragraph on the history page maybe?
>> 
>> wdyt?
>> 
>> 
>>> 
>>> In case of plugins: the major represents the minimal required version of
>>> Maven.
>>> 
>>> Robert
>>> On 4-4-2021 11:28:30, Romain Manni-Bucau wrote:
>>> Hi Elliotte,
>>> 
>>> My goal is to write what we can promise and users can rely on to work.
>>> If we can only promise any major release will get all security fixes
>>> whatever are the minor/patch versions, be it.
>>> I just want what we do to be explicit.
>>> 
>>> Hervé proposed to reference history page of website, it can be a good
>> start
>>> with one or two more sentences to solve that.
>>> 
>>> Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a
>>> écrit :
>>> 
>>>> On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau
>>>> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> What about starting from something like
>>>>> http://tomee.apache.org/security/security.html for our versioning
>>>> policy.
>>>>> 
>>>>> Goal is really to let user plan their versioning policy and ensure
>>> there
>>>> is
>>>>> no big surprises in the needed upgrades to have bugfixes.
>>>>> 
>>>> 
>>>> TBH I don't think we have enough developer time and commitment to
>> promise
>>>> this.
>>>> 
>>>> --
>>>> Elliotte Rusty Harold
>>>> elh...@ibiblio.org
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>> 
>>>> 
>>> 
>> 



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

Le dim. 4 avr. 2021 à 14:10, Robert Scholte  a écrit :

> To me all releases can contain security fixes.
> Depending on the risk of the CVE we can decide to do a release with only
> those fixes (see Maven 3.0.5 and 3.8.1)
>

I get that but it does not help users to pick versions and to get any
stability in their build - which is the goal of this thread.
Since you rejected a 3.6.4 for last CVE hitting us I have to admit I have a
hard time to formalize it.
Best I come up is "we'll do what we want" which is hopefully just a
complete misinterpretation of what you mean but hope shows how clueless I
am with such a statement at the moment.
Can you try to refine it please?

Concretely, today I'm starting with a 3.8.1, what am I expecting to use in
5 years for this project trying to get security fixes and being stable (ie
4.x is assumed excluded?)?


>
> Robert
>
> On 4-4-2021 12:14:39, Romain Manni-Bucau  wrote:
> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit :
>
> > I doubt we can or should make any promises, only intentions.
> > If we would have it, I wonder if it cover our choice to skip 3.7.0.
> > To me we need to keep that flexibility.
> >
> > I want to reverse the approach: what could users expect as differences
> > between version x and y.
> >
> > For Maven shouldn't be more complex than:
> > bugfix release-change should be safe "just replace" release with bugfixes
> > and internal improvements.
> > minor release-change should represent relevant new features or (as we saw
> > for 3.8.x) possible breaking builds that can be fixed with configuration.
> > major release-change represents changes to the architecture that might
> > change the behavior.
> > as far as I know this defends all Maven releases up until now.
> >
>
> Does not cover the last release - and is actually the issue I'm suffering
> from right now and why i'd like we cover this case: security fixes. As of
> today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like
> we explicit it (even just saying on each line "can include bugfixes").
> Said differently: the reverse approach you mention only cover the feature
> evolution but not the most important for versioning policy: the security
> policy which is the one which hurt right now.
> As an user, I want to be able to anticipate the versions i can need staying
> as much as possible on a stable version (original version) but upgrading to
> get security fixes.
> If it is fine for you to mention lines 1 and 2 can include security fixes
> i'd be to add this paragraph on the history page maybe?
>
> wdyt?
>
>
> >
> > In case of plugins: the major represents the minimal required version of
> > Maven.
> >
> > Robert
> > On 4-4-2021 11:28:30, Romain Manni-Bucau wrote:
> > Hi Elliotte,
> >
> > My goal is to write what we can promise and users can rely on to work.
> > If we can only promise any major release will get all security fixes
> > whatever are the minor/patch versions, be it.
> > I just want what we do to be explicit.
> >
> > Hervé proposed to reference history page of website, it can be a good
> start
> > with one or two more sentences to solve that.
> >
> > Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a
> > écrit :
> >
> > > On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > What about starting from something like
> > > > http://tomee.apache.org/security/security.html for our versioning
> > > policy.
> > > >
> > > > Goal is really to let user plan their versioning policy and ensure
> > there
> > > is
> > > > no big surprises in the needed upgrades to have bugfixes.
> > > >
> > >
> > > TBH I don't think we have enough developer time and commitment to
> promise
> > > this.
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elh...@ibiblio.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: Security/Versioning policy proposal

[Robert Scholte]

To me all releases can contain security fixes.
Depending on the risk of the CVE we can decide to do a release with only those 
fixes (see Maven 3.0.5 and 3.8.1)

Robert

On 4-4-2021 12:14:39, Romain Manni-Bucau  wrote:
Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit :

> I doubt we can or should make any promises, only intentions.
> If we would have it, I wonder if it cover our choice to skip 3.7.0.
> To me we need to keep that flexibility.
>
> I want to reverse the approach: what could users expect as differences
> between version x and y.
>
> For Maven shouldn't be more complex than:
> bugfix release-change should be safe "just replace" release with bugfixes
> and internal improvements.
> minor release-change should represent relevant new features or (as we saw
> for 3.8.x) possible breaking builds that can be fixed with configuration.
> major release-change represents changes to the architecture that might
> change the behavior.
> as far as I know this defends all Maven releases up until now.
>

Does not cover the last release - and is actually the issue I'm suffering
from right now and why i'd like we cover this case: security fixes. As of
today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like
we explicit it (even just saying on each line "can include bugfixes").
Said differently: the reverse approach you mention only cover the feature
evolution but not the most important for versioning policy: the security
policy which is the one which hurt right now.
As an user, I want to be able to anticipate the versions i can need staying
as much as possible on a stable version (original version) but upgrading to
get security fixes.
If it is fine for you to mention lines 1 and 2 can include security fixes
i'd be to add this paragraph on the history page maybe?

wdyt?


>
> In case of plugins: the major represents the minimal required version of
> Maven.
>
> Robert
> On 4-4-2021 11:28:30, Romain Manni-Bucau wrote:
> Hi Elliotte,
>
> My goal is to write what we can promise and users can rely on to work.
> If we can only promise any major release will get all security fixes
> whatever are the minor/patch versions, be it.
> I just want what we do to be explicit.
>
> Hervé proposed to reference history page of website, it can be a good start
> with one or two more sentences to solve that.
>
> Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a
> écrit :
>
> > On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau
> > wrote:
> > >
> > > Hi all,
> > >
> > > What about starting from something like
> > > http://tomee.apache.org/security/security.html for our versioning
> > policy.
> > >
> > > Goal is really to let user plan their versioning policy and ensure
> there
> > is
> > > no big surprises in the needed upgrades to have bugfixes.
> > >
> >
> > TBH I don't think we have enough developer time and commitment to promise
> > this.
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

Le dim. 4 avr. 2021 à 12:09, Robert Scholte  a écrit :

> I doubt we can or should make any promises, only intentions.
> If we would have it, I wonder if it cover our choice to skip 3.7.0.
> To me we need to keep that flexibility.
>
> I want to reverse the approach: what could users expect as differences
> between version x and y.
>
> For Maven shouldn't be more complex than:
> bugfix release-change should be safe "just replace" release with bugfixes
> and internal improvements.
> minor release-change should represent relevant new features or (as we saw
> for 3.8.x) possible breaking builds that can be fixed with configuration.
> major release-change represents changes to the architecture that might
> change the behavior.
> as far as I know this defends all Maven releases up until now.
>

Does not cover the last release - and is actually the issue I'm suffering
from right now and why i'd like we cover this case: security fixes. As of
today it is a mix between patch (bugfix) and minor lines AFAIK but I'd like
we explicit it (even just saying on each line "can include bugfixes").
Said differently: the reverse approach you mention only cover the feature
evolution but not the most important for versioning policy: the security
policy which is the one which hurt right now.
As an user, I want to be able to anticipate the versions i can need staying
as much as possible on a stable version (original version) but upgrading to
get security fixes.
If it is fine for you to mention lines 1 and 2 can include security fixes
i'd be to add this paragraph on the history page maybe?

wdyt?


>
> In case of plugins: the major represents the minimal required version of
> Maven.
>
> Robert
> On 4-4-2021 11:28:30, Romain Manni-Bucau  wrote:
> Hi Elliotte,
>
> My goal is to write what we can promise and users can rely on to work.
> If we can only promise any major release will get all security fixes
> whatever are the minor/patch versions, be it.
> I just want what we do to be explicit.
>
> Hervé proposed to reference history page of website, it can be a good start
> with one or two more sentences to solve that.
>
> Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a
> écrit :
>
> > On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau
> > wrote:
> > >
> > > Hi all,
> > >
> > > What about starting from something like
> > > http://tomee.apache.org/security/security.html for our versioning
> > policy.
> > >
> > > Goal is really to let user plan their versioning policy and ensure
> there
> > is
> > > no big surprises in the needed upgrades to have bugfixes.
> > >
> >
> > TBH I don't think we have enough developer time and commitment to promise
> > this.
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Security/Versioning policy proposal

[Robert Scholte]

I doubt we can or should make any promises, only intentions.
If we would have it, I wonder if it cover our choice to skip 3.7.0.
To me we need to keep that flexibility.

I want to reverse the approach: what could users expect as differences between 
version x and y.

For Maven shouldn't be more complex than:
bugfix release-change should be safe "just replace" release with bugfixes and 
internal improvements.
minor release-change should represent relevant new features or (as we saw for 
3.8.x) possible breaking builds that can be fixed with configuration.
major release-change represents changes to the architecture that might change 
the behavior.
as far as I know this defends all Maven releases up until now.

In case of plugins: the major represents the minimal required version of Maven.

Robert
On 4-4-2021 11:28:30, Romain Manni-Bucau  wrote:
Hi Elliotte,

My goal is to write what we can promise and users can rely on to work.
If we can only promise any major release will get all security fixes
whatever are the minor/patch versions, be it.
I just want what we do to be explicit.

Hervé proposed to reference history page of website, it can be a good start
with one or two more sentences to solve that.

Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a
écrit :

> On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau
> wrote:
> >
> > Hi all,
> >
> > What about starting from something like
> > http://tomee.apache.org/security/security.html for our versioning
> policy.
> >
> > Goal is really to let user plan their versioning policy and ensure there
> is
> > no big surprises in the needed upgrades to have bugfixes.
> >
>
> TBH I don't think we have enough developer time and commitment to promise
> this.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Security/Versioning policy proposal

[Romain Manni-Bucau]

Hi Elliotte,

My goal is to write what we can promise and users can rely on to work.
If we can only promise any major release will get all security fixes
whatever are the minor/patch versions, be it.
I just want what we do to be explicit.

Hervé proposed to reference history page of website, it can be a good start
with one or two more sentences to solve that.

Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold  a
écrit :

> On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi all,
> >
> > What about starting from something like
> > http://tomee.apache.org/security/security.html for our versioning
> policy.
> >
> > Goal is really to let user plan their versioning policy and ensure there
> is
> > no big surprises in the needed upgrades to have bugfixes.
> >
>
> TBH I don't think we have enough developer time and commitment to promise
> this.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Security/Versioning policy proposal

[Elliotte Rusty Harold]

On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau  wrote:
>
> Hi all,
>
> What about starting from something like
> http://tomee.apache.org/security/security.html for our versioning policy.
>
> Goal is really to let user plan their versioning policy and ensure there is
> no big surprises in the needed upgrades to have bugfixes.
>

TBH I don't think we have enough developer time and commitment to promise this.

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Security/Versioning policy proposal

[Romain Manni-Bucau]

Hi all,

What about starting from something like
http://tomee.apache.org/security/security.html for our versioning policy.

Goal is really to let user plan their versioning policy and ensure there is
no big surprises in the needed upgrades to have bugfixes.

The tomee one spiritI aligns on the 3.6/3.8 jump we just did but adopting
it would make it "user obvious".

Don't think we already have such a page, does it belong to
maven.apache.org/versioning.html or something else?
Wdyt of this kind of page/content?

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>

Re: Maven Shared Components versioning...

[Dennis Lundberg]

+1

2015-09-30 11:12 GMT+02:00 Karl Heinz Marbaise :
> Hi,
>
> i would like to suggest to upgrade all maven-shared components versions to
> 3.0.0 if they use Maven 3.0 dependencies and use JDK 1.6...
>
> (Honestly i have to admit that i already started with Maven Archiver in that
> way but coming to Maven Shared utils which is used by maven archiver to
> upgrade as well)...
>
>
> The reason for that is that we have a clear line of shared components which
> use Maven 3.0 dependencies and we a going in accordance with the plugins
> which should have the same version 3.0.0 if the are Maven 3.0 JDK 6 only
> ...based on our discusses roadmap
>
>
> Any objections ? Ideas / Improvements ?
>
> Kind regards
> Karl Heinz Marbaise
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



-- 
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Maven Shared Components versioning...

[Karl Heinz Marbaise]

Hi,

i would like to suggest to upgrade all maven-shared components versions 
to 3.0.0 if they use Maven 3.0 dependencies and use JDK 1.6...


(Honestly i have to admit that i already started with Maven Archiver in 
that way but coming to Maven Shared utils which is used by maven 
archiver to upgrade as well)...



The reason for that is that we have a clear line of shared components 
which use Maven 3.0 dependencies and we a going in accordance with the 
plugins which should have the same version 3.0.0 if the are Maven 3.0 
JDK 6 only ...based on our discusses roadmap



Any objections ? Ideas / Improvements ?

Kind regards
Karl Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[fluido] versioning the produced css/js

[Simone Tripodi]

Hi all guys,

time ago Robert and I were discussing about versioning the produced
minified css/js to avoid browser cache conflicts, I mean, ATM all
fluido skin versions refer to

$relativePath/js/apache-maven-fluido.min.js
$relativePath/js/apache-maven-fluido.min.cs

that could cheat users when upgrading skins, since they could have
been cached by the browser and while rendering the site, the old
css/js could be used.

I think it would be good versioning the produced resources according
to the current fluido skin version, such as

$relativePath/js/apache-maven-fluido-${project.version}.min.js
$relativePath/js/apache-maven-fluido-${project.version}.min.cs

WDYT?
TIA and all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [fluido] versioning the produced css/js

[Olivier Lamy]

2012/8/22 Simone Tripodi simonetrip...@apache.org:
 Hi all guys,

 time ago Robert and I were discussing about versioning the produced
 minified css/js to avoid browser cache conflicts, I mean, ATM all
 fluido skin versions refer to

 $relativePath/js/apache-maven-fluido.min.js
 $relativePath/js/apache-maven-fluido.min.cs

 that could cheat users when upgrading skins, since they could have
 been cached by the browser and while rendering the site, the old
 css/js could be used.

 I think it would be good versioning the produced resources according
 to the current fluido skin version, such as

 $relativePath/js/apache-maven-fluido-${project.version}.min.js
 $relativePath/js/apache-maven-fluido-${project.version}.min.cs

 WDYT?

Definitely +1 !

 TIA and all the best!
 -Simo

 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [fluido] versioning the produced css/js

[Tony Chemit]

On Wed, 22 Aug 2012 13:22:56 +0200
Olivier Lamy ol...@apache.org wrote:

 2012/8/22 Simone Tripodi simonetrip...@apache.org:
  Hi all guys,
 
  time ago Robert and I were discussing about versioning the produced
  minified css/js to avoid browser cache conflicts, I mean, ATM all
  fluido skin versions refer to
 
  $relativePath/js/apache-maven-fluido.min.js
  $relativePath/js/apache-maven-fluido.min.cs
 
  that could cheat users when upgrading skins, since they could have
  been cached by the browser and while rendering the site, the old
  css/js could be used.
 
  I think it would be good versioning the produced resources according
  to the current fluido skin version, such as
 
  $relativePath/js/apache-maven-fluido-${project.version}.min.js
  $relativePath/js/apache-maven-fluido-${project.version}.min.cs
 
  WDYT?
 
 Definitely +1 !

+1

yes, as anything in life, versioning is a requirement (when two versions can 
exist :)).


tony.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [fluido] versioning the produced css/js

[Simone Tripodi]

Thanks for the feedbacks guys, I just quickly took care about it, see MSKINS-61

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Aug 22, 2012 at 1:29 PM, Tony Chemit che...@codelutin.com wrote:
 On Wed, 22 Aug 2012 13:22:56 +0200
 Olivier Lamy ol...@apache.org wrote:

 2012/8/22 Simone Tripodi simonetrip...@apache.org:
  Hi all guys,
 
  time ago Robert and I were discussing about versioning the produced
  minified css/js to avoid browser cache conflicts, I mean, ATM all
  fluido skin versions refer to
 
  $relativePath/js/apache-maven-fluido.min.js
  $relativePath/js/apache-maven-fluido.min.cs
 
  that could cheat users when upgrading skins, since they could have
  been cached by the browser and while rendering the site, the old
  css/js could be used.
 
  I think it would be good versioning the produced resources according
  to the current fluido skin version, such as
 
  $relativePath/js/apache-maven-fluido-${project.version}.min.js
  $relativePath/js/apache-maven-fluido-${project.version}.min.cs
 
  WDYT?

 Definitely +1 !

 +1

 yes, as anything in life, versioning is a requirement (when two versions can 
 exist :)).


 tony.

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [fluido] versioning the produced css/js

[Robert Scholte]

Nice!

-Robert

Op Wed, 22 Aug 2012 13:44:56 +0200 schreef Simone Tripodi  
simonetrip...@apache.org:


Thanks for the feedbacks guys, I just quickly took care about it, see  
MSKINS-61


best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Aug 22, 2012 at 1:29 PM, Tony Chemit che...@codelutin.com  
wrote:

On Wed, 22 Aug 2012 13:22:56 +0200
Olivier Lamy ol...@apache.org wrote:


2012/8/22 Simone Tripodi simonetrip...@apache.org:
 Hi all guys,

 time ago Robert and I were discussing about versioning the produced
 minified css/js to avoid browser cache conflicts, I mean, ATM all
 fluido skin versions refer to

 $relativePath/js/apache-maven-fluido.min.js
 $relativePath/js/apache-maven-fluido.min.cs

 that could cheat users when upgrading skins, since they could have
 been cached by the browser and while rendering the site, the old
 css/js could be used.

 I think it would be good versioning the produced resources according
 to the current fluido skin version, such as

 $relativePath/js/apache-maven-fluido-${project.version}.min.js
 $relativePath/js/apache-maven-fluido-${project.version}.min.cs

 WDYT?

Definitely +1 !


+1

yes, as anything in life, versioning is a requirement (when two  
versions can exist :)).



tony.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

About Maven3 M2Eclipse Plug-in Versioning Problem

[Barışcan Güngör]

Hi,

 

At first, thanks for your attention and time to read.

 

In our enterprise applications we use MyEclipse 8.5 with
M2Eclipse maven3 plug-in support. Before begining to use maven3, with maven2 we
could specify a variable for the application version in the parent pom, so that
in the child poms we could able to specify the version by the same variable.
That helps us saving our time for updating version number in each project
upgrade and for reusability. 

 

I hope I can clearly demonstrate the problem as the
following piece of code for pom.xml’s. 

Now the problem is in maven3 (m2eclipse) it gives a warning
that says “version must be a constant instead of a variable”. I have been
trying lots of variations such as moving out the version tag or
swapping the expressions between projectVersion and version
tags or the other suggestions from the different forum sites, etc.. However,
the solution never comes up.. Maybe I am doing something wrong, but could not
find out yet. 

 

Any help would be appreciated,

Many thanks in advance,

Bariscan

 

BTW, you can check the case from here:

 

PARENT:

project

  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;

  xmlns=http://maven.apache.org/POM/4.0.0;

  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

  modelVersion4.0.0/modelVersion

  groupIdcom.gg.n3gservices/groupId

  artifactIdn3gservices/artifactId

  namen3gservices Maven
Main/name

  packagingpom/packaging

  descriptionVersion Alias:
MemberProfitLocalService /description 

  version${projectVersion}/version

  properties

   
projectVersion2.4/projectVersion

  /properties

 

Child;

project

  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;

  xmlns=http://maven.apache.org/POM/4.0.0;

  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

  modelVersion4.0.0/modelVersion

  groupIdcom.gg.n3gservices/groupId

  artifactIdn3gservicesBugfix/artifactId

  namen3gservices Bugfix/name

  parent

   
artifactIdn3gservices/artifactId

   
groupIdcom.gg.n3gservices/groupId

   
relativePath../n3gservices/pom.xml/relativePath

   
version${projectVersion}/version

  /parent

version${projectVersion}/version



--
Barışcan Güngör
Matematik Mühendisi
+905322277334

baris...@w.cn

  
_
Hotmail: Powerful Free email with security by Microsoft.
https://signup.live.com/signup.aspx?id=60969

Re: About Maven3 M2Eclipse Plug-in Versioning Problem

[Benjamin Bentmann]

Barışcan Güngör wrote:


Now the problem is in maven3 (m2eclipse) it gives a warning
that says “version must be a constant instead of a variable”.


A POM deployed to a repository must be self-contained in the way that 
all information required to process it (e.g. calculate the effective 
POM) must be present in the POM.


This does not hold for a POM referencing its parent via an external 
property. Until Maven provides support to (partly) interpolate 
properties before deployment, using properties for POM coordinates is an 
anti-pattern that enables deployment of broken POMs, i.e. that can't be 
used during dependency resolution as we have already seen in the past 
for stuff in central.


Regarding easier version maintenance for multi-module projects, right 
now I can only suggest to use the Release Plugin and to vote for MNG-624.



Benjamin

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: About Maven3 M2Eclipse Plug-in Versioning Problem

[Benjamin Bentmann]

Barışcan Güngör wrote:


[...] we
could specify a variable for the application version in the parent pom, so that
in the child poms we could able to specify the version by the same variable.
That helps us saving our time for updating version number in each project
upgrade and for reusability.


Oh, and I likely should have mentioned the

  http://mojo.codehaus.org/versions-maven-plugin/

(sorry Stephen ;-) )


Benjamin

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: About Maven3 M2Eclipse Plug-in Versioning Problem

[Stephen Connolly]

No worries... though I need to call a vote to get a 3.0-beta-1 compatible
version published

2010/5/17 Benjamin Bentmann benjamin.bentm...@udo.edu

 Barışcan Güngör wrote:

  [...] we

 could specify a variable for the application version in the parent pom, so
 that
 in the child poms we could able to specify the version by the same
 variable.
 That helps us saving our time for updating version number in each project
 upgrade and for reusability.


 Oh, and I likely should have mentioned the

  http://mojo.codehaus.org/versions-maven-plugin/

 (sorry Stephen ;-) )



 Benjamin

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

RE: About Maven3 M2Eclipse Plug-in Versioning Problem

[Martin Gainty]

 
//did you try setting the necessary properties in settings.xml or profiles.xml 
e.g.?


profilesXml

  /profiles
profile
  idappserverConfig/id
  properties
version1.0/version
  /properties

/profile

  /profiles

  activeProfiles
activeProfileappserverConfig/activeProfile
  /activeProfiles
/profilesXml


http://maven.apache.org/guides/introduction/introduction-to-profiles.html
Martin Gainty 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.Ce message est confidentiel et peut être 
privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec 
bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non 
autorisée ou la copie de ceci est interdite. Ce message sert à l'information 
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant 
donné que les email peuvent facilement être sujets à la manipulation, nous ne 
pouvons accepter aucune responsabilité pour le contenu fourni.



 

 From: baris...@w.cn
 To: dev@maven.apache.org
 Subject: About Maven3 M2Eclipse Plug-in Versioning Problem
 Date: Mon, 17 May 2010 15:53:28 +0300
 
 
 
 
 Hi,
 
 
 
 At first, thanks for your attention and time to read.
 
 
 
 In our enterprise applications we use MyEclipse 8.5 with
 M2Eclipse maven3 plug-in support. Before begining to use maven3, with maven2 
 we
 could specify a variable for the application version in the parent pom, so 
 that
 in the child poms we could able to specify the version by the same variable.
 That helps us saving our time for updating version number in each project
 upgrade and for reusability. 
 
 
 
 I hope I can clearly demonstrate the problem as the
 following piece of code for pom.xml’s. 
 
 Now the problem is in maven3 (m2eclipse) it gives a warning
 that says “version must be a constant instead of a variable”. I have been
 trying lots of variations such as moving out the version tag or
 swapping the expressions between projectVersion and version
 tags or the other suggestions from the different forum sites, etc.. However,
 the solution never comes up.. Maybe I am doing something wrong, but could not
 find out yet. 
 
 
 
 Any help would be appreciated,
 
 Many thanks in advance,
 
 Bariscan
 
 
 
 BTW, you can check the case from here:
 
 
 
 PARENT:
 
 project
 
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd;
 
 xmlns=http://maven.apache.org/POM/4.0.0;
 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 
 modelVersion4.0.0/modelVersion
 
 groupIdcom.gg.n3gservices/groupId
 
 artifactIdn3gservices/artifactId
 
 namen3gservices Maven
 Main/name
 
 packagingpom/packaging
 
 descriptionVersion Alias:
 MemberProfitLocalService /description 
 
 version${projectVersion}/version
 
 properties
 
 
 projectVersion2.4/projectVersion
 
 /properties
 
 
 
 Child;
 
 project
 
 xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/maven-v4_0_0.xsd;
 
 xmlns=http://maven.apache.org/POM/4.0.0;
 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 
 modelVersion4.0.0/modelVersion
 
 groupIdcom.gg.n3gservices/groupId
 
 artifactIdn3gservicesBugfix/artifactId
 
 namen3gservices Bugfix/name
 
 parent
 
 
 artifactIdn3gservices/artifactId
 
 
 groupIdcom.gg.n3gservices/groupId
 
 
 relativePath../n3gservices/pom.xml/relativePath
 
 
 version${projectVersion}/version
 
 /parent
 
 version${projectVersion}/version
 
 
 
 --
 Barışcan Güngör
 Matematik Mühendisi
 +905322277334
 
 baris...@w.cn
 
 
 _
 Hotmail: Powerful Free email with security by Microsoft.
 https://signup.live.com/signup.aspx?id=60969
  
_
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1

integration test versioning policy?

[Brett Porter]

Hi,

I ran the ITs against 3.0-alpha-3 and got a number of failures.

Several of those are because they are fixed in 3.0-alpha-4 but marked to run 
for all versions:
- mng4412OfflineModeInPlugin
- mng4433ForceParentSnapshotUpdate

Before correcting anything I would like to check I understand the policy 
correctly: should the versions be set to the versions for which the tests 
should run 100%? Or is there a deliberate move to show failures where something 
didn't work because of a regression (such as the ones above)?

Thanks,
Brett
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: integration test versioning policy?

[Brian Fox]

There should be a start and end range for the tests. These new ones
start in alpha-4-snapshot and end ]

On Thu, Nov 12, 2009 at 8:20 AM, Brett Porter br...@apache.org wrote:
 Hi,

 I ran the ITs against 3.0-alpha-3 and got a number of failures.

 Several of those are because they are fixed in 3.0-alpha-4 but marked to run 
 for all versions:
 - mng4412OfflineModeInPlugin
 - mng4433ForceParentSnapshotUpdate

 Before correcting anything I would like to check I understand the policy 
 correctly: should the versions be set to the versions for which the tests 
 should run 100%? Or is there a deliberate move to show failures where 
 something didn't work because of a regression (such as the ones above)?

 Thanks,
 Brett
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: integration test versioning policy?

[Brett Porter]

On 13/11/2009, at 1:08 AM, Brian Fox wrote:

 There should be a start and end range for the tests. These new ones
 start in alpha-4-snapshot and end ]

ok, I've fixed these 2 and 4361 based on your other comment (though I haven't 
changed the JIRA version of that issue).

I also included all versions of 2.0 in the valid ranges since I believe these 
were working cases in earlier versions.

- Brett


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Versioning java smells for animal-sniffer

[Stephen Connolly]

OK, here is the problem set:

For animal-sniffer, we need to have signatures of each of the java runtime
libraries (i.e. the animal smells/scents)

That way animal-sniffer can detect whether you are compatible with a
specific java runtime library.

Initially I was going to have these signatures as primary artifacts, so you
would have one pom.xml for each java version...

Then jason and a few others felt that these were not really a packaging
type, and it would be better to have them as secondary artifacts...

Actually this is somewhat better... as we can differentiate by classifier
and add value using the classifier...

Of course we then hit the question, how should we divide things up?  in the
following bgid=org.codehaus.mojo.animal-sniffer

Option 1:

bgid:java:1.0:java11, bgid:java:1.0:java12, bgid:java:1.0:java13,
bgid:java:1.0:java14, bgid:java:1.0:java15, bgid:java:1.0:java16

pros:
* if we generate bad signatures, we can just rev the version number and
people can just pick up the new rev
anti:
* version ranges cannot be used to pick a signature range
* no room for differentiating vendor specific signatures
* signature descriptions would have to be limited to broad sweeps, e.g. all
of java 1.4... and thus we could miss some signature differences between
1.4.0, 1.4.1 and 1.4.2... unless we use java140, java141, java142 as the
classifiers [just plain ugly]

Option 2:

bgid:java:1.1.0-1, bgid:java:1.2.2-1, bgid:java:1.3.2-20,
bgid:java:1.4.2-19, bgid:java:1.5.0-19, bgid:java:1.6.0-15

pros:
* version ranges now specify the version of java that you are after.
* we still have classifier for vendor specific signatures
anti:
* what happens if we find that 1.4.2-19 is bad and we have already generated
the signatures for 1.4.2-20... we cannot up the build number as the next one
is taken, we cannot add a qualifier as qualifier  no qualifier, and we've
used up all the segments that maven 2.x supports

Option 3:

bgid:java1:1.0.1, bgid:java1:2.2.1, bgid:java1:3.2.20, bgid:java1:4.2.19,
bgid:java1:5.0.19, bgid:java1:6.0.15

pros:
* we have the build number to fix bad signatures
* for 5.0+ the version number matches the marketeers version number for java
* we still have classifiers for vendor specific signatures
anti:
* not the version numbers that people are expecting

Option 4:

bgid:java11:1.0, bgid:j2se12:1.0, bgid:j2se13:1.0, bgid:j2se14:1.0,
bgid:javase5:1.0, bgid:javase6:1.0

pros:
* plenty of room on version numbers
* still have classifiers
anti:
* now version ranges are no use for specifying the signatures to check.

Thoughts anyone? other options?

-Stephen

Re: Versioning java smells for animal-sniffer

[Brett Porter]

Can you avoid cross posting? I went to reply to this on d...@mojo and  
it had the reply-to of this list as gmail merges the messages.


If you aren't getting the answers you're seeking on d...@mojo you can  
post here to point people at it, but cross posting in general is kinda  
evil :)


Thanks,
Brett

On 18/09/2009, at 6:41 AM, Stephen Connolly wrote:


OK, here is the problem set:

For animal-sniffer, we need to have signatures of each of the java  
runtime

libraries (i.e. the animal smells/scents)

That way animal-sniffer can detect whether you are compatible with a
specific java runtime library.

Initially I was going to have these signatures as primary artifacts,  
so you

would have one pom.xml for each java version...

Then jason and a few others felt that these were not really a  
packaging

type, and it would be better to have them as secondary artifacts...

Actually this is somewhat better... as we can differentiate by  
classifier

and add value using the classifier...

Of course we then hit the question, how should we divide things up?   
in the

following bgid=org.codehaus.mojo.animal-sniffer

Option 1:

bgid:java:1.0:java11, bgid:java:1.0:java12, bgid:java:1.0:java13,
bgid:java:1.0:java14, bgid:java:1.0:java15, bgid:java:1.0:java16

pros:
* if we generate bad signatures, we can just rev the version number  
and

people can just pick up the new rev
anti:
* version ranges cannot be used to pick a signature range
* no room for differentiating vendor specific signatures
* signature descriptions would have to be limited to broad sweeps,  
e.g. all
of java 1.4... and thus we could miss some signature differences  
between
1.4.0, 1.4.1 and 1.4.2... unless we use java140, java141, java142 as  
the

classifiers [just plain ugly]

Option 2:

bgid:java:1.1.0-1, bgid:java:1.2.2-1, bgid:java:1.3.2-20,
bgid:java:1.4.2-19, bgid:java:1.5.0-19, bgid:java:1.6.0-15

pros:
* version ranges now specify the version of java that you are after.
* we still have classifier for vendor specific signatures
anti:
* what happens if we find that 1.4.2-19 is bad and we have already  
generated
the signatures for 1.4.2-20... we cannot up the build number as the  
next one
is taken, we cannot add a qualifier as qualifier  no qualifier, and  
we've

used up all the segments that maven 2.x supports

Option 3:

bgid:java1:1.0.1, bgid:java1:2.2.1, bgid:java1:3.2.20,  
bgid:java1:4.2.19,

bgid:java1:5.0.19, bgid:java1:6.0.15

pros:
* we have the build number to fix bad signatures
* for 5.0+ the version number matches the marketeers version number  
for java

* we still have classifiers for vendor specific signatures
anti:
* not the version numbers that people are expecting

Option 4:

bgid:java11:1.0, bgid:j2se12:1.0, bgid:j2se13:1.0, bgid:j2se14:1.0,
bgid:javase5:1.0, bgid:javase6:1.0

pros:
* plenty of room on version numbers
* still have classifiers
anti:
* now version ranges are no use for specifying the signatures to  
check.


Thoughts anyone? other options?

-Stephen



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Vincent Siveton]

Hi Juan,

I just deployed 1.1-SNAPSHOT artifacts.

Cheers,

Vincent

2009/1/6, Juan F. Codagnone juan-o...@zauber.com.ar:
 Hi Vincent,

   I also think the 1.1-SNAPSHOT could be deployed on
  http://people.apache.org/repo/m2-snapshot-repository/. 1.0-beta-1-SNAPSHOT is
  the only version available there.

  Juan.


  On Monday 29 December 2008 10:13:32 Vincent Siveton wrote:
   Hi Dennis,
  
   Thanks for this!
  
   Vincent
  
   2008/12/28, Dennis Lundberg denn...@apache.org:
JIRA is done now. I've changed the names of the versions in JIRA in the
 following way, for both DOXIA and DOXIASITETOOLS:
   
 Old version - New version
   
 1.0-beta-1  - 1.1
 1.0-beta-2  - 1.2
 1.0 - 1.3
   
 I also added a 1.0 version for each project. They currently have no
 issues connected to them.
   
 Vincent Siveton wrote:
  Hi Dennis,
 
  I renamed branches, did an external on the branches, updated some
  poms. I leave you Jira and the 1.0 release.
 
  Cheers,
 
  Vincent
 
  2008/12/14 Vincent Siveton vincent.sive...@gmail.com:
  Hi Dennis,
 
  2. Rename
  http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branc
 hes/doxia-sitetools-1.0-alpha-x/ to
  http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branc
 hes/doxia-sitetools-1.0.x/
 
  I didn't remember this branch... Thanks to refresh my memory :)
 
  So, I suggest also to create an external on these branches. I
  propose: https://svn.apache.org/repos/asf/maven/doxia/1.0-x with
  doxia
  https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-1.0
 .x/ doxia-sitetools
  https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches
 /doxia-1.0.x/
 
  Also, think to update the scm tag in the poms :)
 
  - apply new versioning in pom
 
  Yes, either before the release or during release:prepare, for both
  the branch and trunk.
 
  Before is better IMHO
 
  What else?
 
  For the 1.0 release I think that covers it.
 
  Shall we divide up the work between us Vincent?
  If I do the 1.0 release can you do the 1.1 release?
 
  Sounds good for me.
 
  Cheers,
 
  Vincent
   
--
   
Dennis Lundberg


 --
  Buenos Aires, Argentinahttp://juan.zauber.com.ar/

Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Dennis Lundberg]

Lukas Theussl wrote:
 
 One side remark about the site: for doxia-1.1 (was 1.0-beta-1) we have
 modified the  apt format with the plan to render obsolete the original
 apt used in maven 2.0.x. If we are going to support and maintain both
 doxia-1.0 (was alpha branch) and doxia-1.1 then we have to keep both
 formats documented on the doxia site. It's not a big problem since we
 have already separate docs for the old style and the changes in the new
 format [1]. I can take care to add notes about the different versions in
 those documents, or should we keep two completely different descriptions
 of the apt format on the site? Or two different web sites (for 1.0 and
 1.1) altogether?

I think one set of documents is enough, if it includes notes about what
has changed over time.


 -Lukas
 
 [1]
 https://svn.apache.org/repos/asf/maven/doxia/site/src/site/apt/references/
 
 
 Dennis Lundberg wrote:
 JIRA is done now. I've changed the names of the versions in JIRA in the
 following way, for both DOXIA and DOXIASITETOOLS:

 Old version - New version

 1.0-beta-1  - 1.1
 1.0-beta-2  - 1.2
 1.0 - 1.3

 I also added a 1.0 version for each project. They currently have no
 issues connected to them.



 


-- 
Dennis Lundberg

Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Lukas Theussl]

One side remark about the site: for doxia-1.1 (was 1.0-beta-1) we have modified 
the  apt format with the plan to render obsolete the original apt used in maven 
2.0.x. If we are going to support and maintain both doxia-1.0 (was alpha branch) 
and doxia-1.1 then we have to keep both formats documented on the doxia site. It's 
not a big problem since we have already separate docs for the old style and the 
changes in the new format [1]. I can take care to add notes about the different 
versions in those documents, or should we keep two completely different 
descriptions of the apt format on the site? Or two different web sites (for 1.0 
and 1.1) altogether?


-Lukas

[1] https://svn.apache.org/repos/asf/maven/doxia/site/src/site/apt/references/


Dennis Lundberg wrote:

JIRA is done now. I've changed the names of the versions in JIRA in the
following way, for both DOXIA and DOXIASITETOOLS:

Old version - New version

1.0-beta-1  - 1.1
1.0-beta-2  - 1.2
1.0 - 1.3

I also added a 1.0 version for each project. They currently have no
issues connected to them.

Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Vincent Siveton]

Hi Dennis,

Thanks for this!

Vincent

2008/12/28, Dennis Lundberg denn...@apache.org:
 JIRA is done now. I've changed the names of the versions in JIRA in the
  following way, for both DOXIA and DOXIASITETOOLS:

  Old version - New version

  1.0-beta-1  - 1.1
  1.0-beta-2  - 1.2
  1.0 - 1.3

  I also added a 1.0 version for each project. They currently have no
  issues connected to them.



  Vincent Siveton wrote:
   Hi Dennis,
  
   I renamed branches, did an external on the branches, updated some poms.
   I leave you Jira and the 1.0 release.
  
   Cheers,
  
   Vincent
  
   2008/12/14 Vincent Siveton vincent.sive...@gmail.com:
   Hi Dennis,
  
   2. Rename
   
 http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0-alpha-x/
   to
   
 http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0.x/
   I didn't remember this branch... Thanks to refresh my memory :)
  
   So, I suggest also to create an external on these branches. I propose:
   https://svn.apache.org/repos/asf/maven/doxia/1.0-x with
   doxia   
 https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-1.0.x/
   doxia-sitetools 
 https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-1.0.x/
  
   Also, think to update the scm tag in the poms :)
  
   - apply new versioning in pom
   Yes, either before the release or during release:prepare, for both the
   branch and trunk.
   Before is better IMHO
  
   What else?
   For the 1.0 release I think that covers it.
  
   Shall we divide up the work between us Vincent?
   If I do the 1.0 release can you do the 1.1 release?
   Sounds good for me.
  
   Cheers,
  
   Vincent
  
  



 --

 Dennis Lundberg

Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Brett Porter]

I have a question about this...

Does this mean that MNG-3402 should be rescheduled for 2.1.0 now,  
instead of 2.0.11?


I have updated the wiki - and have pushed the upgrade to beta-1 out to  
2.1.0-M3 so that we can push out another milestone in the mean time.


Cheers,
Brett

2008/12/16 Vincent Siveton vincent.sive...@gmail.com
Hi Dennis,

I renamed branches, did an external on the branches, updated some poms.
I leave you Jira and the 1.0 release.

Cheers,

Vincent

2008/12/14 Vincent Siveton vincent.sive...@gmail.com:
 Hi Dennis,

 2. Rename
 
http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0-alpha-x/
 to
 
http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0.x/

 I didn't remember this branch... Thanks to refresh my memory :)

 So, I suggest also to create an external on these branches. I  
propose:

 https://svn.apache.org/repos/asf/maven/doxia/1.0-x with
 doxia   
https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-1.0.x/
 doxia-sitetools 
https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-1.0.x/

 Also, think to update the scm tag in the poms :)

 - apply new versioning in pom

 Yes, either before the release or during release:prepare, for both  
the

 branch and trunk.

 Before is better IMHO

 What else?

 For the 1.0 release I think that covers it.

 Shall we divide up the work between us Vincent?
 If I do the 1.0 release can you do the 1.1 release?

 Sounds good for me.

 Cheers,

 Vincent




--
Brett Porter
http://blogs.exist.com/bporter/

Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Vincent Siveton]

Hi Brett,

I think we could have the following:
Doxia 1.0 should be for Maven 2.0.x
Doxia 1.1 should be for Maven 2.1.x/3.x with a fix for MNG-3402

Cheers,

Vincent

2008/12/18 Brett Porter br...@apache.org:
 I have a question about this...

 Does this mean that MNG-3402 should be rescheduled for 2.1.0 now, instead of
 2.0.11?

 I have updated the wiki - and have pushed the upgrade to beta-1 out to
 2.1.0-M3 so that we can push out another milestone in the mean time.

 Cheers,
 Brett

 2008/12/16 Vincent Siveton vincent.sive...@gmail.com
 Hi Dennis,

 I renamed branches, did an external on the branches, updated some poms.
 I leave you Jira and the 1.0 release.

 Cheers,

 Vincent

 2008/12/14 Vincent Siveton vincent.sive...@gmail.com:
 Hi Dennis,

 2. Rename

 http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0-alpha-x/
 to

 http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0.x/

 I didn't remember this branch... Thanks to refresh my memory :)

 So, I suggest also to create an external on these branches. I propose:
 https://svn.apache.org/repos/asf/maven/doxia/1.0-x with
 doxia
 https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-1.0.x/
 doxia-sitetools
 https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-1.0.x/

 Also, think to update the scm tag in the poms :)

 - apply new versioning in pom

 Yes, either before the release or during release:prepare, for both the
 branch and trunk.

 Before is better IMHO

 What else?

 For the 1.0 release I think that covers it.

 Shall we divide up the work between us Vincent?
 If I do the 1.0 release can you do the 1.1 release?

 Sounds good for me.

 Cheers,

 Vincent




 --
 Brett Porter
 http://blogs.exist.com/bporter/

Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Vincent Siveton]

Hi Dennis,

I renamed branches, did an external on the branches, updated some poms.
I leave you Jira and the 1.0 release.

Cheers,

Vincent

2008/12/14 Vincent Siveton vincent.sive...@gmail.com:
 Hi Dennis,

 2. Rename
 http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0-alpha-x/
 to
 http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0.x/

 I didn't remember this branch... Thanks to refresh my memory :)

 So, I suggest also to create an external on these branches. I propose:
 https://svn.apache.org/repos/asf/maven/doxia/1.0-x with
 doxia   
 https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-1.0.x/
 doxia-sitetools 
 https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-1.0.x/

 Also, think to update the scm tag in the poms :)

 - apply new versioning in pom

 Yes, either before the release or during release:prepare, for both the
 branch and trunk.

 Before is better IMHO

 What else?

 For the 1.0 release I think that covers it.

 Shall we divide up the work between us Vincent?
 If I do the 1.0 release can you do the 1.1 release?

 Sounds good for me.

 Cheers,

 Vincent

Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Vincent Siveton]

Hi Dennis,

 2. Rename
 http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0-alpha-x/
 to
 http://svn.eu.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-sitetools-1.0.x/

I didn't remember this branch... Thanks to refresh my memory :)

So, I suggest also to create an external on these branches. I propose:
https://svn.apache.org/repos/asf/maven/doxia/1.0-x with
doxia   
https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-1.0.x/
doxia-sitetools 
https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/branches/doxia-1.0.x/

Also, think to update the scm tag in the poms :)

 - apply new versioning in pom

 Yes, either before the release or during release:prepare, for both the
 branch and trunk.

Before is better IMHO

 What else?

 For the 1.0 release I think that covers it.

 Shall we divide up the work between us Vincent?
 If I do the 1.0 release can you do the 1.1 release?

Sounds good for me.

Cheers,

Vincent

Re: Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Vincent Siveton]

Some actions items:
- rename the actual doxia branch to 1.0.x and create a new branch for
sitetools (and probably for tools) I propose to use the alpha tag code
to do this. Create a new branch 1.0.x for all doxia projects sounds
better.
- apply new versioning in pom
- update jira

What else?

Cheers,

Vincent

2008/12/13 Vincent Siveton vincent.sive...@gmail.com:
 Hi Dennis,

 2008/12/12 Dennis Lundberg denn...@apache.org:
 Hi Vincent

 Can we have a quit poll about version numbering. We have had discussions
 about this in the past and I'd like to come to a conclusion now that the
 release is getting closer.

 The proposal that was made earlier was this:

 1. Create an Doxia 1.0 release from the current doxia-1.0-alpha-x branch

 +1


 2. Release the current trunk as version 1.1 (currently labeled as
 1.0-beta-1 in JIRA)

 +1


 One reason for this change would be to get out of the alpha/beta mess.

 +1

 It would also align version numbers nicely with Maven and the Site Plugin.

 hehe it's about dumb luck :)


 We would the have two parallel tracks:

 Track one: Maven 2.0.x + Doxia 1.0.x + Site Plugin 2.0.x

 Track two: Maven 2.1.x + Doxia 1.1.x + Site Plugin 2.1.x

 This also ties in with the Doxia Release Plan [1]

 I will have some time off from work during the holidays and will be able
 to help.


 WDYT?

 Two releases rather one, good xmas presents!

 If no objections, I will start to prepare these releases, jump in when
 you are free.

 Cheers,

 Vincent


 [1] http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan

Doxia Versioning (WAS Preparation of Doxia 1.0-beta-1 release)

[Vincent Siveton]

Hi Dennis,

2008/12/12 Dennis Lundberg denn...@apache.org:
 Hi Vincent

 Can we have a quit poll about version numbering. We have had discussions
 about this in the past and I'd like to come to a conclusion now that the
 release is getting closer.

 The proposal that was made earlier was this:

 1. Create an Doxia 1.0 release from the current doxia-1.0-alpha-x branch

+1


 2. Release the current trunk as version 1.1 (currently labeled as
 1.0-beta-1 in JIRA)

+1


 One reason for this change would be to get out of the alpha/beta mess.

+1

 It would also align version numbers nicely with Maven and the Site Plugin.

hehe it's about dumb luck :)


 We would the have two parallel tracks:

 Track one: Maven 2.0.x + Doxia 1.0.x + Site Plugin 2.0.x

 Track two: Maven 2.1.x + Doxia 1.1.x + Site Plugin 2.1.x

 This also ties in with the Doxia Release Plan [1]

 I will have some time off from work during the holidays and will be able
 to help.


 WDYT?

Two releases rather one, good xmas presents!

If no objections, I will start to prepare these releases, jump in when
you are free.

Cheers,

Vincent


 [1] http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan