Page MenuHomeFreeBSD

*/py-dj31-*: Deprecate Django 3.1 ports and consumers
ClosedPublic

Authored by kai on Sep 2 2021, 6:45 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Nov 25, 3:45 PM
Unknown Object (File)
Nov 5 2024, 2:08 PM
Unknown Object (File)
Oct 15 2024, 11:43 AM
Unknown Object (File)
Oct 7 2024, 11:10 AM
Unknown Object (File)
Oct 1 2024, 11:13 AM
Unknown Object (File)
Sep 29 2024, 9:17 AM
Unknown Object (File)
Sep 28 2024, 10:39 PM
Unknown Object (File)
Sep 28 2024, 2:02 AM
Subscribers

Details

Summary
*/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>
Test Plan
  • All Django 3.1 consumers should be listed in this diff as well.

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kai requested review of this revision.Sep 2 2021, 6:45 AM
kai created this revision.

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?

koobs requested changes to this revision.Sep 6 2021, 3:31 AM
  • 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. :)
This revision now requires changes to proceed.Sep 6 2021, 3:31 AM

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

Address @koobs's suggestions regarding the deprecation messages.

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

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.

In D31782#718519, @kai wrote:

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

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.

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

This revision is now accepted and ready to land.Sep 6 2021, 8:47 AM
koobs retitled this revision from *: Deprecate Django 3.1 and its consumers to */py-dj31-*: Deprecate Django 3.1 ports and consumers.Sep 6 2021, 8:52 AM
koobs edited the summary of this revision. (Show Details)
This revision was automatically updated to reflect the committed changes.