glib2-devel should track unstable releases again

[ryandesign (Ryan Carsten Schmidt)]

IOW [e4b92aad19d1990ab89487ce77916a11998de61f/macports-ports] should be reverted.

[mascguy (Christopher Nielsen)]

Well, there can be significant churn between unstable releases, adding more headaches to deal with. In addition, the goal is to pre-test stable releases for folks, before rolling out to the masses.

So let's keep it tracking stable releases, as that alone still involves ample work.

[ryandesign (Ryan Carsten Schmidt)]

The original goal was to notice problem in unstable releases before those problems made it to stable releases.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

The original goal was to notice problem in unstable releases before those problems made it to stable releases.

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.

[jmroot (Joshua Root)]

I would recommend renaming the port if it's not actually going to install unstable versions as implied by the -devel suffix.

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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 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.