Branches and aliases

Creating Neos & Flow Code
1

Right now we have some packages that have both a branch and an alias for the same version. Here is an example:

Flowpack_Neos_FrontendLogin__Git_.png1308×816 90.5 KB

While that works (technically) it is confusing:

  • composer update just told me it updated from 2.0.x to dev-master, which made me wonder.
  • we have a 3.0 branch and even a 3.0.0 tag but it still installs dev-master.

We could use the branch alias to our advantage, and keep working on master. That would free us of having to maintain one more branch and from thinking about the target branch for each change. OTOH it means we have to be vary careful with not adding breaking changes to the master branch; and we should remove the 3.0 branch to avoid confusion.

What do you think about that?

2

Wait what?

It sounds very dangerous, also practically removes the possibility to merge stuff for after 3.0 already.

3

Can’t fully grasp the consequences, so I can’t really take a stance :confused:

we have to be vary careful with not adding breaking changes to the master branch

But this sounds bad - only merge breaking changes into release branches then? In that case we would need to create the release branches much much earlier IMO - optimally as soon as a previous release is published. Or do I miss something?

4

Hey there, noticed this while tagging new versions of a bunch of those packages and thought I cleared up most of them? At least the example you mention, doesn’t have a 3.0 branch since I deleted it in favor of using a branch alias (maybe you only looked locally?). There should never be a branch and a branch alias for the same of course, that’s bad.

If composer installs dev-master, then you must have set a minimum-stability flag that allows it or required that specific version. Unless you mean composer is saying dev-master, while it’s actually the branch alias version it’s installing?

Keep in mind that one should avoid using dev branches all together and make sense to release stable versions instead, unless it’s required for a new unreleased version of course.

I added branch aliases consistently to the package I dealt with, since it was a bit of a mess already where there were some with duplicates, some without it as it seemed branches had just been created for all of them without taking those branches using aliases into account.

Personally I like using branch aliases to avoid having two identical branches and having to upmerge, especially since many of the packages have little activity besides bugfixes and rarely have any breaking changes.

It means that one cannot merge breaking changes without branching off the existing branch and bumping the branch alias, but to me that’s definitely okay as breaking changes should really be carefully considered in any case and justifying the need for a new branch in that process makes sense.