During launch of a new version, composer can pull in dev-master

[dmnc]

Just noticed this during the push out of 1.13.4.

If you have "minimum-stability": "dev", in an app composer.json, then when some of the zf1s/zend-* packages have been released but others haven't you can pull in dev-master.

I think this is a combination of the branch alias in each package (1.x-dev to dev-master) and the fact that when there is a release, all requirements get bumped to ^1.13.4.

As an example, https://github.com/zf1s/zend-xml/blob/master/composer.json requires "zf1s/zend-exception": "^1.13.4" but if only 1.13.3 is visible in packagist, it picks dev-master instead.

I know this is an edge case, but it isn't ideal. I can see a couple of potential solutions:

1. Have interdependencies as "^1.13" unless there is a cascading bug that needs to be fixed in two places at once.
   or
2. Only bump the versions on the packages that actually change.

I am assuming the second would be a pretty painful change to process.

[glensc]

@dmnc you mean the problem you describe happens within minutes of between:

1. developer releases zf1 new version
2. packagist updates each of the packages

[falkenhawk]

No I am afraid it's because https://github.com/symplify/monorepo-builder which I use here to split the monorepo and push to individual package repos takes ~20 minutes to go through and roll out all packages, one by one.

I will need to look into it to see if monorepo-builder would allow me to first do the split and update all repos without pushing tags (to avoid triggering packagist, and then quickly just push only tags at the end of the process. It would still be possible to "break" some of the installations if they update during the final tags push, but at least if they fall back to dev-master (the case mentioned by @dmnc when "minimum-stability": "dev" is configured), that would be already the latest code. 🤔

[dmnc]

@dmnc you mean the problem you describe happens within minutes of between:

1. developer releases zf1 new version
2. packagist updates each of the packages

As above, it's because there is quite a time gap between the first package being on packagist and the last. I had assumed it was due to a manual process, but the effect is the same.

[glensc]

the final push impact could be minimized if dependencies are sorted first. i.e packages that have no dependencies are pushed first, then packages that depend only on packages pushed in the first round, etc.

but it may be an impossible task if there are cross-dependencies.

perhaps the simple way to prevent this problem in the first place is to push monorepo tag last, i.e that's probably why @dmnc started to update their dependencies, as they got email notification of released tag (same as me).

btw, I started a branch at some point to automate the release process:

• https://github.com/glensc/php-zf1s/commits/releaser

idea was if the process is scriptable with a simple command, integrate it with CI (GitHub Actions).

[falkenhawk]

The newest monorepo-builder is very promising (9.0.0 beta2 released just a week ago) - they dropped handling the split through php code in favor of github actions: deprecated-packages/symplify#2490
And it does its job in a matter of only few minutes on their monorepo: https://github.com/symplify/symplify/actions?query=workflow%3A%22Split+Monorepo%22 (pushing all packages in parallel)

[glensc]

The monorepo builder being replaced with bunch of git commands, seems to me going backward in time.

If the previous version preserved commit messages:

• https://github.com/zf1s/zend-xmlrpc/commits/5f645ae25b22557abb8ef171b81e4e7904bd3211

then new version just has commit messages titled "$link_to_github":

• https://github.com/symplify/github-actions/blob/d69a0986813d0f7a8a38b6e40256d0e655b00797/packages/monorepo-split-github-action/entrypoint.sh#L61-L68

maybe fine for their use, but not ready for general use.

but otoh, if you only update the splits with new version only, probably doesn't matter much.

[falkenhawk]

new version just has commit messages titled "$link_to_github": I don't like it either tbh

[glensc]

also, the previous version synchronized every commit when you made release (I think), then the new version with the github actions (that's implemented now) is unreliable as if the action fails, the sync will be omitted, and there's no way to retry it. and when you make new push (unaware that previous failed), it will commit over previous change that was left unsynchronized, in effect merge two commits.

Perhaps there are other open-source tools for the repo splitting. I don't know what tool they use, but here's some:

• https://github.com/symfony/symfony -> symfony/*
• https://github.com/docker/docker-ce#unifying-upstream-sources

if I'd ought wrote a repo splitter from scratch, I'd probably use:

• https://github.com/newren/git-filter-repo

there's nothing wrong using GitHub actions (I like event based flows), just the action code must not assume everything done before completed successfully.