On Nov 1, 2018, at 21:41, George Plymale II wrote: > Hi all, > > Recently, I was trying to use some features that had been committed to > Macports' base recently. One of them was my own feature which was > accepted in this PR: https://github.com/macports/macports-base/pull/99 > > However, as I tried to use this feature it simply would not work. At > first, I was scared that I'd stumbled on some sort of hideous heisenbug; > that my code actually wasn't working even though it had already been > accepted and I tested it previously. Upon further investigation, though, > it seems that actually my Macports' base is missing some commits, even > though it's on the latest version 2.5.4. > > According to porthier(7), the sources of my base are located under: > /opt/local/var/macports/sources > > By following the directory tree, I found the folder I was interested in: > /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base/src/pextlib1.0 > > As I looked in this folder, I noticed that many files had timestamps of > 2017, including readline.c which is the specific file I was interested > in. I confirmed that this file really was not up-to-date with the master > branch. Here is the file's commit history: > https://github.com/macports/macports-base/commits/master/src/pextlib1.0/readline.c > > As you can see, the most recent change since 2017 was the rebranding of > "OS X" to "macOS." My version of readline.c does not even have this > update; the file contains many references to "OS X" and no references to > "macOS." Clearly, some commits are missing from my base tree. > > Furthermore, upon examining the commits between 2.5.3 and 2.5.4 it is > apparent that some commits on the master branch are missing: > https://github.com/macports/macports-base/compare/v2.5.3...v2.5.4 > > So what's going on? I guess this must be part of Macports' release > system and only certain commits are picked for release. I can't think of > any other explanation, at least. Why is this done? How long does it take > (and what are the criteria) before a base commit is actually released? I > don't see any documentation describing the release process. I'm glad at > least to know that my changes were not infected with any heisenbugs, but > after all this investigation I'd like to know what's going on! Consider > my curiosity piqued, I guess :) > > Thanks, > - George Plymale II
Hi George, Commits to the macports-ports repository are distributed to users automatically, without further review, as quickly as the content can be synchronized to the rsync servers, which usually happens within an hour of each change. Commits to the macports-base repository on the other hand are tested by developers first, then accumulated into manually-created releases, which are published on our web site and distributed to users via selfupdate. You can see our prior release history here: https://github.com/macports/macports-base/releases and here: https://github.com/macports/macports-base/blob/master/ChangeLog If your PR is a bug fix, we could consider it for inclusion in the next bugfix release of MacPorts; if we make such a release it will be 2.5.5. If your PR is a new feature, it would go into the next feature release, which would be 2.6.0 (or conceivably 3.0.0 if we feel such a jump in version number is warranted). That's also why you'll find commits on master that were not released in 2.5.4. We only backport specific changes, designed to fix specific bugs, from master to the current release branch. Other changes have to wait for the next feature release. New releases of MacPorts base are made by portmgr (Joshua, Rainer, and me) when it seems like a good time to do so. We collectively make the decision to release a new version, usually asking the community if any other changes should be included in the upcoming release, and then one of us actually makes the release (that's been Joshua lately). For example, we needed to make a change for better compatibility with Mojave, so we released 2.5.4 recently for that reason. If another critical bug were found, that would probably motivate us to release a new version quickly. Less critical changes will probably have to wait until several changes can be released together at once. There is no set schedule for MacPorts base releases. It would be good if we could make more frequent releases to get fixes out there, even if they're smaller or not super critical. One reason we don't do this is because our release process involves a great deal of manual labor. I hope to automate more of the process using our buildbot, but we're not there yet.
