Re: Security/Versioning policy proposal

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

Re: Security/Versioning policy proposal

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

Re: Security/Versioning policy proposal

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

Re: Security/Versioning policy proposal

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

Re: [VOTE] Release Apache Maven JXR Plugin version 3.1.1

Hi Robert, > Regarding the voting, every vote counts, maybe especially from users. > Depending on the release manager, their negative votes might result in the > cancelling of the release. > A few years ago we decided to drop the word "binding" during the vote, > because it doesn't motivate non-

JDK 17 Early Access build 18 is available

*Hi Robert , * *OpenJDK 17 Early Access build 18is now available at **https://jdk.java.net/17 * * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception