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
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.
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.
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
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:
Synchronize the release cycle and version numbers with neos-development-collection (but still keep neos-ui as a separate repo)
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.
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
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.
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
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.
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.
I just stumbled over this discussion, because I myself was also very confused on which version we should now use in Neos 4.3. We are in the means of upgrading a big site, and ended up with neos-ui 1.4.1 due to the fact that this is what the upgrade steps recommended:
Since these two paths are the most common ways of “getting the new UI”, someone should at least take care of keep that up-to-date with what you want us to use as a “stable version”.
I would even prefer to require neos-ui:* and let you (the releasers of the package) to specify in which version each particular version is compatible with, so that the upgrade instructions don’t even need to mention it, because the newest compatible version will be installed. Of course that requires you to follow the semantic versioning of the neos package, which makes sense anyway!
great to see your name here in the Neos discuss.
The Neos.Neos.Ui package is at the moment not part of the neos-development-collection. That was a good thing for developing the new react-ui. We had more flexibility and was not forced to the Neos CMS release cycle.
This will change with version 5.0 of Neos. But at the moment we have two branches in the UI.
2.x versions are Neos 3.3 compatible
3.x branch is Neos 4.x compatible
The version 1.x is not getting any updates.
Hope that helps to make it clearer. If not feel free to ask
