This deprecates the non-lts versions of OpenJDK, to discourage
installing the, from the ports tree. I have not set a expiration date
for the ports yet, as I think it's worth discussing this a bit before
deciding on hard timeframes.
Details
Details
- None
Diff Detail
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 69195 Build 66078: arc lint + arc unit
Event Timeline
Comment Actions
Are we planning to remove these ports from the tree at some point? If so, you should also set EXPIRATION_DATE.
Ignore me. I somehow missed your comment above when I wrote this.
Comment Actions
DEPRECATED without EXPIRATION_DATE is pointless. Please follow this procedure:
- Starting with the oldest one put an EXPIRATION_DATE of 30 days ahead. Like openjdk18 30D+NOW. OpenJDK19 60D+NOW and onwards.
- Make sure that every ports has a PORTREVISION bump. So that any users who needs/uses this also needs to reinstall the ports and get a notification that their used ports are getting removed.
- Also merge quarterly.
It's a lengthy procedure but safer. But as now we have someone looking at the OpenJDK ports try to align with the upstream and whenever they mark a version EOL mark that DEPRECATED. Normally for Java it's safe to align with the quarterly end date for Expiration. So if a version reaches EOL on let's say 15th April you can set it to the end of quarter like 0630.
Comment Actions
@bofh Thanks! That's exactly the kind of feedback I was looking for.
I agree it's pointless to just set a deprecation without and expiration date, but was unsure about what the proper procedure for expiring ports like this was.
Comment Actions
While committing please add the MFH marker. Like MFH: 2025Q4. And also remove the dots at the end of the DEPRECATED.