[MacPorts] #69052: glib2-devel should track unstable releases again

[MacPorts]

#69052: glib2-devel should track unstable releases again
--------------------------+---------------------
  Reporter:  ryandesign   |      Owner:  mascguy
      Type:  defect       |     Status:  closed
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:  wontfix      |   Keywords:
      Port:  glib2-devel  |
--------------------------+---------------------

Comment (by ryandesign):

 Replying to [comment:3 mascguy]:
 > Sure, but that will also involve updating multiple times between
 unstable releases - potentially causing us to chase our tails, as upstream
 refines their approach prior to a final official release - and it's simply
 not practical time-wise.

 It's your port now so of course you can manage it how you like. But when I
 was maintaining this port, and the other -devel ports I maintain/ed, it
 was not a problem to update to development versions; if it had been I
 never would have created those ports since that was their purpose. In the
 ideal case of updating any port, it's nothing more than updating the
 version and checksums and verifying it builds and maybe running the tests.
 If it fails, you have the opportunity to report that to the developers so
 they can fix it before the next stable version is released. This is much
 better than having a new stable version released and only then discovering
 a show-stopping problem. More than once I've seen bug reports for a new
 stable version of something where the developers bemoan that nobody
 apparently tested their prerelease versions where the problem might have
 been caught before release.

 It also gives you a chance to become acquainted with the changes in the
 next stable version gradually with each unstable release rather than
 having to process everything, and potentially deal with multiple issues,
 all at once. And a small subset of users will install the -devel ports and
 report problems, often problems they encounter building other ports that
 depend on those ports, giving you early notice of problems that will need
 fixing in those dependents.

 I think it's fine for a -devel port to test out other portfile changes
 before making them available to everyone. Sometimes this goes hand in hand
 with version updates. minivmac, for example, experienced significant
 changes in its build system during the development of version 36 and it
 was helpful to track the alpha versions of 36 in the minivmac-devel port
 and iron out any issues with the new build system before updating the
 minivmac port to 36. Other times, the changes aren't directly related to
 the version, like in the cmake-devel port where the moving of some files
 to subports was tested out.

 Replying to [comment:4 jmroot]:
 > I would recommend renaming the port if it's not actually going to
 install unstable versions as implied by the -devel suffix.

 What suffix do you suggest? -devel is the only suffix we've sanctioned
 thus far. I guess -staging might be a more accurate description if we want
 to encompass more than development versions. (There is one port with a
 -staging suffix that this naming convention would conflict with, dosbox-
 staging, which is actually for a project of that name.)

 However, the notion of development releases is I think becoming more
 scarce. The GNOME project abandoned the practice in 2020, and graphviz did
 recently as well. Simply documenting the fact that the -devel suffix might
 be for new development versions or other experimental portfile changes
 might be better than introducing a new suffix and having to retrain users.

-- 
Ticket URL: <https://trac.macports.org/ticket/69052#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS