*/py-dj31-*: Deprecate Django 3.1 ports and consumers Django 3.1 will reach its End-of-Life in December 2021. Set the deprecation note and expiration date accordingly. Approved by: koobs (python) Differential_Revision: D31782 MFH: Yes|No <reason>
Details
Details
- Reviewers
sunpoet koobs - Group Reviewers
Python - Commits
- R11:57d484328acf: *: Deprecate Django 3.1 and its consumers
- See also https://www.djangoproject.com/download/ at chapter "Supported versions".
- All Django 3.1 consumers should be listed in this diff as well.
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
To resume @koobs's suggestion from D30977 (https://reviews.freebsd.org/D30977#700968) regarding setting only EXPIRATION_DATE:
That would technically work, but it would rather raise more questions than it would be of any use, e.g. "Why is there's an expiration date but no description with the reason for it?"
IMHO, it would make more sense to introduce an additional variable, e.g. UPSTREAM_EXPIRATION_DATE or similar, which would then only be informational and be some kind of "soft expiration date".
@sunpoet : Are you OK with the deprecation of your Django 3.1 ports?
Comment Actions
- Use terminology upstream uses
- Link to the upstream url so users have details
- Mention the EoL date(s) in the message
- 'Has expired' is not accurate/correct semantically, particularly for a port that hasn't reached the EXPIRATION_DATE yet.
Something like:
DEPRECATED=Upgrade to Django 3.2+. Mainstream support ended (April 6, 2021). Extended support ends December 2021 (https://www.djangoproject.com/download/) `` Sorry to ask that all those ports messages be updated. This is why we need framework support for Django, we could deprecate them all in one go. :)
Comment Actions
I'm -1 on a new/separate variable, and maintain that having an expiration date (end-of-life etc) being 'deprecated' (now) logically and semantically makes sense. The reason why porters handbook
says otherwise [1] is because these variables have ports/framework/implementation specific meanings, somewhat more overloaded than a pure metadata or only-descriptive definition. For example EXPIRATION_DATE is used to delete ports, where from a maintainer perspective, its valuable to be able to describe an end-of-life date at any time, all the way from port creation to the time its deleted. This would for example allow for automatic 'messages' to users as they 'approached' that date, progressively getting 'stronger' as they got closer.
[1] "It is possible to set DEPRECATED without an EXPIRATION_DATE (for instance, recommending a newer version of the port), but the converse does not make any sense."
Comment Actions
Ah, ok, I got somewhat misled by the phrase I wonder what breaks if EXPIRATION_DATE is set without DEPRECATED. :) from https://reviews.freebsd.org/D30977#700968. :)
Of course, this makes sense, provided that an EoL date is known from upstream, to put it into DEPRECATED without an EXPIRATION_DATE in a timely manner. A new variable would then be completely superfluous.
Comment Actions
Well, I actually did mean "put it in EXPIRATION_DATE", using the variable as a 'end-of-life' indicator, without using DEPRECATED (until closer to that date). This way you could add EoL metadata to any port at any time, as early as possible, giving users a heads up WAAAYYYYYYY in advance.
The only reason I'm -1 on a separate variable, is that contrary to the PH declaration that 'it doesn't make sense', EXPIRATION_DATE-without_DEPRECATED has clear meaning and value to the user and maintainers. So if we can use it like that, we don't need a different variable.
OTOH, i'm not particularly a fan of most overloaded and unclear variables (in their naming, rather than their usage), so maybe a better scheme for additional package metadata would be better. We certainly have many many examples and needs in that area.
This change looks good to go Kai :)