New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[New Product] Add Apache Maven build tool #1914
Conversation
I don't understand what's wrong with the file π€ ...any help is welcome π |
It's missing a layout: product |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guess the |
Left a few comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully things will look better now @captn3m0 π€ (and thank you for your reveiw and tips π )
products/apache-maven.md
Outdated
releases: | ||
- releaseCycle: "3.8" | ||
eol: false | ||
support: 2023-11-24 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not see any end-of-support dates / EOL dates on https://maven.apache.org/docs/history.html. Could you add the link(s) containing that information in the product description ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still, not sure what to put for 3.x EoLs...
@adriens :
So it would be safer to assume only 3.8.x is maintained with no support / EOL dates:
And other versions are EOL, for instance:
For anyone looking at this example, yes there was no official Apache Maven releases between 3.6.3 (2019-11-25) and 3.8.1 (2021-04-04) ;). @captn3m0 any thought about this ? |
@captn3m0, the product layout is the default layout according to |
I have fixed changelogtemplate now links should work correct |
Let me check and file a PR |
I switched from tracking the maven git repo to tracking the maven maven repo π instead. The Apache release process is 3 step:
We noted this when our tomcat automation (tracking the git repo) pre-published released, because the vote hadn't passed on them. Switching to the maven repo also gives us the 2.x tags as a benefit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have changed EoLs cf #1914 (comment)
Super cool job πͺ about Apache release process π― |
EoLs have been patched, including "guessed EoLs" |
Here is what I mean : diff --git a/products/apache-maven.md b/products/apache-maven.md
index 162d6f2..3a2c44d 100644
--- a/products/apache-maven.md
+++ b/products/apache-maven.md
@@ -33,29 +33,36 @@ releases:
releaseDate: 2018-10-24
- releaseCycle: "3.5"
- eol: 2021-04-04
- support: 2021-04-04
+ eol: 2018-10-24
+ support: 2018-10-24
latest: "3.5.4"
latestReleaseDate: 2018-06-21
releaseDate: 2017-04-07
- releaseCycle: "3.3"
- eol: 2021-04-04
- support: 2021-04-04
+ eol: 2017-04-07
+ support: 2017-04-07
latest: "3.3.9"
latestReleaseDate: 2015-11-14
releaseDate: 2015-03-18
- releaseCycle: "3.2"
- eol: 2021-04-04
- support: 2021-04-04
+ eol: 2015-03-18
+ support: 2015-03-18
latest: "3.2.5"
latestReleaseDate: 2014-12-20
releaseDate: 2014-02-21
+- releaseCycle: "3.1"
+ eol: 2014-02-21
+ support: 2014-02-21
+ latest: "3.2.5"
+ latestReleaseDate: 2013-10-04
+ releaseDate: 2013-07-15
+
- releaseCycle: "3.0"
- eol: 2021-04-04
- support: 2021-04-04
+ eol: 2013-07-15
+ support: 2013-07-15
latest: "3.0.5"
latestReleaseDate: 2013-02-23
releaseDate: 2010-10-08
@@ -65,7 +72,7 @@ releases:
support: 2014-02-18
latest: "2.2.1"
latestReleaseDate: 2009-11-08
- releaseDate: 2005-10-20
+ releaseDate: 2009-06-30
- releaseCycle: "2.1"
eol: 2014-02-18
@@ -79,9 +86,9 @@ releases:
support: 2014-02-18
latest: "2.0.11"
latestReleaseDate: 2010-02-26
- releaseDate: 2005-10-20
+ releaseDate: 2005-10-20
-- releaseCycle: "1.1"
+- releaseCycle: "1.0"
eol: 2014-02-18
support: 2014-02-18
latest: "1.1" Anyway, I wonder if we should simplify things and only keep major versions (1, 2, 3), like it was done for https://endoflife.date/gradle. @captn3m0 what do you think ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit better thanks to #1914 (comment) @marcwrobel review
Is it better now @marcwrobel ? |
Support date for release cycle 3.3 is still wrong. Apart from that everything else looks OK. We still have to decide if we should simplify things and only keep major versions (1, 2, 3), like it was done for https://endoflife.date/gradle (in this PR or in another PR). Waiting for feedback from @captn3m0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here we go for #1914 (comment) @marcwrobel
It should only remain to [...]decide if we should simplify things and only keep major versions (1, 2, 3), |
Just rebased the branch and removed the unnecessary layout override. |
I just have a question ? do we or anyone else need version history for minor releases ? |
No special opinion at this poit (I'm a newbee here πΈ ) |
you are not the problem here , I also want to keep version history and it might be helpful for future but we need |
@usta, that was what I meant in #1914 (comment). I also think it makes more sense to only keep track of the major versions, like we did for https://endoflife.date/gradle. I squashed the older commits and added a new one that change release cycles from |
Sure @marcwrobel π Go ahead π πͺ |
Didn't get to see this earlier, but +1 to using major versions as release cycles here. We should only split those up if multiple are supported at any given time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, let's start with that.
Using major versions as release cycles: each minor version deprecates the previous one.
β About
Apache Maven is a very used and well known buld tool for java.
π Related resources
I have used Maven Releases History as a base data for the pull request.
π Maven usage stats
From this tweet :