Composer, RedirectHandler & branch aliases

Creating Neos & Flow Code
1

I created a PR that introduces a branch alias (a first in the project): TASK: Adjust composer manifest by kdambekalns · Pull Request #1 · neos/redirecthandler · GitHub. That in turn is used by TASK: Adjust composer manifest by kdambekalns · Pull Request #1 · neos/redirecthandler-databasestorage · GitHub.

Now the usefulness of this needs to be discussed, as the comments show. My reasoning was this:

  • using unbound version constraints (* or >1.0) is bad as that can break without warning and in confusing ways
  • creating a branch (in this case) seems too early: the code will be adjusted, we are before a first release and having a branch would just mean that people might work against master by accident or we’d have to upmerge
  • branch aliases allow to work around both issues in a defined way

I’d like to know why @christianm

would also try to avoid that branch alias thing if possible.

The potential issue @aertmann brought up should be non-existent, since it’s an alias all ways (dev-master and 1.0.x-dev and ~1.0@dev) should work. I’ll test this to make sure (unless someone beats me to it).

2

Hey Karsten, seems like you’re missing the point I was making, which doesn’t really have anything to do with using a branch alias or not.

Adding a dependency on Flow or Neos in a specific version (e.g. ~3.2 or ~2.2), means that you cannot install the package with dev-master of Flow or Neos. This is the reason why we have 1.0 branches for the SEO and GoogleAnalytics package, where the only real difference is the dependency to Neos.

Personally I think using a branch alias to avoid having two almost identical branches is a good idea, however that means we need a looser dependency on Flow or Neos (e.g. >=3.2 instead of ~3.2) to allow installing it with dev-master of Flow or Neos.

3

I will keep out of this discussion right now, because of holidays and you should solve it before I am back around really. I saw the same point @aertmann is making basically. So there you go.

4

Well, sine we know that the master of Flow will be 3.3, we should add an alias there, too. That way we could get rid of a bunch of dev-master dependencies and avoid having unbound dependencies (since ~3.2 also allows 3.3).

Or we do ~3.2 || dev-master in the depending package… but I wanted to add branch aliases for a while, but we never knew what the next version would be. With the fixed release scheme that is a problem of the past.

2 Likes
5

For me go with branch alias. Can make more noise/test also because of holidays.

6

I see, that could work as well. I don’t really prefer one over the other, just that we don’t make it so the package cannot be installed with the dev-master version of Flow/Neos. One downside / upside of that approach is that we have to update the compatibility when we create a new major version of Flow/Neos. That forces us to be deliberate with the package actually being compatible with the new major version, which is fine IMO.

Anyway +1 from my side to add those branch aliases to the independent packages and the collections you’ve been wanting to do.

7

I just tested this, a package with a branch alias can be required with version constraints matching the “real” and the “alias” branch. If you like to test this, try to require https://packagist.org/packages/kdambekalns/test-a with

{
    "name": "root/deps",
    "require": {
    	"kdambekalns/test-a": "dev-master"
    }
}

and

{
    "name": "root/deps",
    "require": {
    	"kdambekalns/test-a": "~1.0@dev"
    }
}