Neos UI releases


(Markus Günther) #1

In the team tiga weekly meeting the topic of the releases pops up regarding the neos-ui.
It turns out that it is not clear to all members how we release and when we release.

We are actually developing against 2.x branch which is for the older neos versions and the master branch getting these changes via upmerges. That leads to the problem that people rarely test the master branch. But this branch is the branch that is used for the latest neos version. So my personal opinion is that we maybe have some issues in the past because we test the master not that much.

And if people checkout master and test it - they test the version of the last release. Because when I not wrong the master only gets updates while releasing a new version.

So we (team tiga) thought that we probably discuss the way we release the UI and try to find improvements to test better and earlier.

I don`t want to blame someone. The team is doing a great job and we just need to become better :slight_smile:


(Jon Uhlmann) #2

As I said, I would appreciate if we could upmerge to master at least once a week, to have a chance to test the UI.


(Markus Günther) #3

By the way, was not sure if we should discuss that in public or here. So I choose the save way. When it is ok to that in public we can move the thread.


(Markus Günther) #4

Hi there,

as we have not that much responses, I will come up with an idea first.
We could solve the outdated master branch with the tools we already have I guess.
We have this jenkins instance and GitHub offers webhooks that could also call the Jenkins.

So my idea is to keep master and 2.x in sync with a new Jenkins job and we trigger this job with a webhook on the merge of the PR in the 2.x branch.

That will not solve all issues but we are up to date in 2.x and master. What do you think? That could be an easier tasks than overhaul the whole release procedure at once. But we should keep the release topic on the table I guess.


(Dmitri Pisarev) #5

Hi Markus!
Sorry, missed the thread.

First of all, this thread should definitely be public. We are a super transparent project and discuss in public way more sensitive topics than this one :wink:

From what I know from senior team members, automated upmerges is a very dangerous thing, so we probably shouldn’t do it. Besides, all of our other repos don’t have automated upmerges and seem to get along quite fine. I usually only do upmerges before a release, but perhaps we could just do an additional weekly upmerge.

I think much bigger issue is that we don’t have a proper release cycle in the first place.
What I would do:

  1. Synchronize the release cycle and version numbers with neos-development-collection (but still keep neos-ui as a separate repo)
  2. Stop adding features for Neos 3.3, only bugfixes (see 1.).
    In other words rename ‘2.x’ branch to ‘3.3’, master to ‘4.0’, create ‘4.1’, ‘4.2’, ‘4.3’ branches from it, new features would go only to master.

We wanted to do something like this starting with Neos 5.0, but I don’t see why we can’t start doing right now, starting with Neos 4.3.


(Markus Günther) #6

Hi Dmitri,

no problem. Nobody can have all feeds on the table. The suggested solution sounds good to me and then master is again a real development branch. Guess this is a bit weird at the moment, the master is not the “up to date” branch like all people a know the a master branch for.

Lets see what the others say and then hopefully lets do it :slight_smile:


(Martin Ficzel) #7

No need to sync the numbers. But syncing the cycle is a goog idea marketing wise. Would work like with Neos.Seo and now Neos.Demo who all habe their own versioning but contribute to the release post once bigger changes went in.

The schema is actually a slightly different in the dev-distributions. Until a release is prepared all changes go to master. During major/minor release preparation the new branch is forked from master and recieves bugfixes from that on. Upmerges then go from the versions chain up until they finally end in master.


(Dmitri Pisarev) #8

Having version numbers in-sync would allow to do things like ‘“neos/neos”: “self.version”’ and in general it would help not to get crazy converting these version numbers in one’s mind all the time…

The problem is that neos-ui 3.3 is already taken. Maybe we could start getting version numbers in-sync since 4.x, and keep 2.x releases as bugfix releases for Neos 3.3.

Sure, that’s exactly what I meant actually.

Actually that’s often the case with our development collections too, when something is fixed in minor branches and not yet upmerged. But yeah, there’ll be less confusion since at least features would always go to master.

Would anyone volunteer to help setup the new versioning schema for the UI? I’m personally not able to dive deep into it at the moment unfortunately :frowning:


(Martin Ficzel) #9

I personally prefer to have the peer dependencies (neos but not dev-dist package) not that tightly coupled as it forces us into release synchronization issues.

For Demo and SEO the releases were done a week before and the version constraint in dev-dist was updated accordingly. UI was handled the same and it actually felt correct.

If you really want to use self.version then the ui should go into the dev-distribution.


(Dmitri Pisarev) #10

Okay, I see the point, makes sense.
But if possible I’d still like to have version numbers in-sync, that would be easier to grasp both by us and by the users.


(Bastian Waidelich) #11

I think the actual issue is not so much the compatibility between specific Neos versions per se but the lack of Semantic Versioning in the UI package.

I see why it wasn’t practicable to introduce that too early, but I think we should shift to a more strict release cycle.