Thank you, Fred. Good afternoon. So, Maritz and I do a lot in the clone community together, but we are, for most, we are colleagues at software. And a few weeks ago, I talked with Maritz. Look, Maritz, wouldn't it be great if we could show people on World Clone Day the amount of work you do and what it

takes to get a new clone release out. And we get new plan releases out almost every month now because the monthly release schedule for clone six is in the monthly release schedule. So, Maritz, I was able to convince you. So, what are we going to release today?

We're going to release clone 604, or at least a release candidate of that. If you have time, we could do a final release of clone 5 to 12, actually. So, we'll see how far we come.

Yeah, so what I understood indeed, clone 6 is now monthly because there's still a lot of stuff happening there and we want to follow up. But clone 5.2 is now on a three monthly release cycle, right? So, we had like 5 to 10 early this year and now at the end of this quarter, it would be 5 to 12. It was, right? Yeah, we had 5 to 11 in January and then 5 to 12 this month.

And then we'll get another in July and in October and then clone 5.2 is out of maintenance support and only security support for another year.

Yeah, that's after... So, it's starting to get to clone 6. Exactly. So, this is a pre-recorded thing for world clone day because maybe around world clone, they will have the final also of this 604. This is a soft release, a release candidate. What does that mean? You asked me earlier that to test a software, so you ask people and me,

you put it, you post it with a posting on community or cloud.org, for example. So, I can download it and you can test it, but it's not the final release. Exactly. This is mostly so people can try it out to see, hey,

does my custom project also work with this or is there something really big or there could always be bugs that appear, but if your clone site doesn't even start for some weird reason, because I've made a mistake and added the, I mean, you start a clone version 1.0 instead of 604,

which would be really weird, but yeah, you just want to pick out... Yeah, you didn't manage that so far. No, so far it's okay. Yeah, no, but it is really valuable. And we did it also for some of our own customer projects locally on the developer machine. It's very easy to switch, make a few switches

and get the soft release of the next minor or patch release. And then you can really test some stuff and see if things are running correctly. Most of the things, it's mostly details that we're looking for, but it really helps, it really helps Maritz and others for people to test those soft releases. So yes, in secret, this is also a bit of a promotion

and not to show how a release is made, but also to make people aware that they can help with the quality of the releases. You're not doing this by heart, right? You don't have this secret list on the wall that we can't see or in your head what you need to do. There is a release checklist. Yeah, I've got a list, just a file in the Plone Core Developments build out

that everyone can see. And when I think, hey, it's now about time to create a new release, then I just paste that on the GitHub in issue and see with Plone and I'll share my screen so everyone can see that. Just a moment. That's the one.

I should soon see, it was faster a bit ago, but. Yeah, we'll see what it was. We're both recording. We'll see. You should be seeing my screen soon. A bit weird that it doesn't show yet, but

now I'm seeing it. Yeah, it should be fine. So I've got the scene of Plone report. Yeah, I've got a checklist of 35 tasks. Most of them are done by me and some by others as well,

and there's a lot of automation in there as well. We won't be going over the full list, I guess, but we can at least start with the overview. First, I have to release some packages so that they are in the PyPI, the Python package index, and update the versions in the Core

development build out. And then I need to create some release notes, update constraints, and put all those files on this.plone.org so people have a canonical version list that they can use. Next one, we'll wait a few days and then we'll make a final release

and we'll create Docker images. Usually Erico or Fred can also do that. Yes, I didn't really realize when I talked to you into giving this talk together with me, that indeed the last part was releasing the Docker images. That's also something

that's maintained by the sysadmin and also CI team a bit, and Erico and me in setting that up. And I've been helping also with getting those releases out on needs, both for the Plone 6 backend, because that's something we need to also explain. We're now

primarily showing the Plone content backend, the backend server, and the classic UI stack. That's what this release is about, because there's also a separate release cycle for the new Plone 6 default frontend for photos. So that's also something to make clear now. We're now focusing on

like half of the release. But then this is a big one because there are a lot of more packages here and this is not to do anything with photo, but photo is also from the release and packaging thing, is a one contained repository where a lot of checks and a lot of things are happening.

But your work has a bit more to do as we'll see shortly. And for the announcements, it's also partially the marketing team and who is on the marketing team. That's Mr. Fred right here. Yeah, they're also helping. I mean, yeah, so we're with five or six people on the marketing team, but indeed, I also picked up

because I know when you're looking to make a release because then we already chatted about it. And I'm also helping now a bit with the news items. I mean, my role is limited there within getting the news item. Yes, and with this new monthly release cycle, we have

something new to tell every month, which also is fun to distill and see what's really in there and new. Okay, Marius, go. Where should we... Yeah, after announcements we're done, I think. Yeah, after announcements it's done. So we'll start at the top here. We won't go into details

for all of them, but yeah, the first check is a really important one. Check the Jenkins status, that should be green. So that's our testing server. I'll quickly check if it's green indeed. One small problem on Plone 5.2, but that's something weird on one of the notes, but here look at Plone 6.2. Yeah, make it a bit bigger.

Of the Plone 6 jobs, green, green, green, green, green. Yeah, so we're testing every... We're testing this release on multiple Python versions. Yeah, so we're seeing, yeah, Plone, this Python 3.8, 3... Wait, that's Plone 5.2.

Plone 6, Python 3.10, 3.11, 3.8, 3.9, yeah, they're sorted alphabetically, so it's a different order. And yeah, and the robot framework tests were all in Chrome, so four different Python versions. That all should work. Usually it's no problem these days, but it can always be tricky

with the newest or the oldest Python version that we support. But currently everything is green and sunny, so I'm happy to make a release today. Yeah, so your checklist is on product-cmf-plone, and product-cmf-plone on our GitHub repo is the canonical repository where the Plone backend and

classic UI server kind of starts. But to clarify to people, all these tests are running in a different repository. Your whole releasing is not done from product-cmf-plone. There's a core development build-out repository. Also, yeah, just visible for everyone. Yeah,

it's open source. And there we really say, okay, more than 100 packages that are really done by the Plone community and all kinds of other packages that are being pulled in. There we say, okay, use version 1, use version 3.1.0. All the versions are really pinned over there. And, yeah,

my most important job as release manager is, yeah, to update those version pins regularly and create new releases when the packages within Plone are being updated. Yeah, because what we see here, everything is green in Jenkins, but Jenkins is actually

running the build-out .coredev repository tests. Yeah, so there are all kinds of tests that are being run. You can see here, Plone 8789 tests have passed, plus 149 robot tests, so that's

a real browser that's actually testing it. So that's a lot of tests, yeah, split over a lot of Plone packages. Next to that, yeah, just, for example, a big part of Plone is Zope. We're not running the Zope tests because, yeah, Zope itself is tested by the Zope community, which in the end

is part of the Plone community. So we're not testing all 300 or so packages, but just, yeah, the Plone packages that we really care about, that we take care of as community. Yeah, they're on test suites, and once the Zope application server has been tested, then we take it as a basis

for our own tests on which Plone is built on top of Zope. Yeah, I think that's probably enough about Jenkins. Yeah, it's our safeguard for making a sound release. If it's green, it's green,

but if it's not green, then it's quite a bit of work for you and others to get it to green. That can be tricky, yeah. And also, every time you create a pull request for a CMF Plone or for another package, that is also being checked on Jenkins, that before we merge anything

to the master or main branches of the repositories, that we make sure, hey, if it would happen, then all the tests pass. That's a lot of secure testing that's being done already before anything goes into the releases.

Yeah, and not to make things more complicated, but these are actually functional integration tests where you test everything together. We've also been working already to have unit tests run locally on the repositories themselves. So unit tests are the kind of tests where you only need the package itself, and you try to abstract away any dependencies by using mock objects,

and those tests run very fast. But we've also been adding those tests steadily since last year on individual packages, but those run on GitHub and not on Jenkins. Yeah, so that's with GitHub Actions and Jenkins. That's really something we do ourselves. It's amazing if you see this, that we

still have sometimes we have small bugs and regressions. You see the testing and the amount of testing that's going on is insane. Not to mention that we're now doing only the back add-ons with classic UI and photo also has these three or four kinds of tests and test suites and

things like that. So here we got Cordef. Yeah, the second part. Yeah, that's it. I don't need to do this. We have a bin manage script that's part of Plone.releaser, which was made by Eric Steele, I guess, already at least 10 years ago, probably when he started on the Plone 4.0

as release manager, or maybe sooner. It's just a small wrapper around Sysreleaser. It has some extra, you know, there's a report command that's being used to check all the packages. Are there any changes in packages that we don't really check out yet in the

core development build outs? These days, it's not really needed that much anymore because we have Mr. Roboto, which works together with Jenkins and GitHub, sits in between a bit. And

a package that really checks if there's a pull request that's being merged. At that point, makes a commit on the core development build outs that adds that package to the checkouts. And you should probably quickly go to my terminal, because this is the core development build outs

that we check. So GitHub clones built out of Cordef. It's over there. And this is going to files and this is imported from checkouts.cfg. This has, whenever, for example, plone.restapi has a pull request merged, then you have Mr. Roboto is active. It listens to all kinds of things that

happen in GitHub. And it edits the checkout.cfg file. And then adds plone.restapi to the list of packages in the auto checkouts. So that's next time that you're on build out, because we're really still using build out and not so much pip for this part, at least. Plone does work.

But this part, it is still called the core development build out. We'll change that at some point, but not yet. So then when you're a developer, you check it out, pull the latest

changes in, run build outs, then you get the latest version of a checkout of plone.restapi as well. I've got a few packages that are always checked out. Like yeah, product seam with Plone, that's always checked out. You always want the latest version of that. And translations, and yeah, a few more there. So Mr. Roboto is a small server that we developed

in the Plone community years ago. I know a party managing it sometimes and restarting it, but I have no clue how it is built internally. But I do know a bit more about how it's working,

as you said, indeed. So for example, I'm just making an example. We have PloneAppEvent. PloneAppEvent is the package that adds the event content type or does something around our events in Plone. Whenever you make a pull request there and it gets merged and there's a webhook, the webhook

does a call in GitHub to Mr. Roboto and Mr. Roboto maintains the whole list of all core packages. Mr. Roboto is then the one that makes a small commit message to build out core dev and updates PloneAppEvent. So PloneAppEvent gets added to the checkout CFG you just showed us. Then he'll build out core dev is running and it starts to test everything with the new changes

in there. That's I think the summary, which I still manage to keep in my head about what's happening on the background. Yeah, that's how that works here. Yeah, just quickly checked it out. It's also just the Plone organization on GitHub that Mr. Roboto wants to have a look at.

It wonders how it works. Everything is in here, including some tests. Yeah, we're still thinking about can we control this later? Maybe we'll do even more with GitHub Actions here, but you have to remember this is a system that has already been running now for at least the last 8 to 10 years

when we didn't have any fans in GitHub, where GitHub was still just a Git repo collection. So this tooling was all built way before that. Yeah, nowadays you could maybe do it differently, but it works fine. So for the moment we're not changing that. Yeah.

Anyway, so the next item is yes, I look at the checkout CFG. Usually when you've been busy for a month as a Plone community, there are a lot of packages in checkout CFG. So me and also Geofocada and sometimes a few others just look at checkout CFG

or they just know, hey, this package needs a checkout or needs a release, and so they release that to the Python package index. And then, yeah, after you release that, you remove it from the checkout CFG again. There's also, for those who know,

there's some automation in there as well because, yeah, the first CFG needs to be updated as well then to use the new version. Currently, yeah, so I've put a check mark in here because there are no non-standard checkouts. There are just the usual suspects like CMF Plone are in there. Yeah, the ones you have to update. The ones you have to update, they have to release.

Yeah, small check here. We have CMF Plone and PloneUp upgrades. They need to be in sync with some versions, but we'll skip that for now. And then we need to handle some special packages of

and handled by special people. I do most of the releases and geofocada, so there's some, I think I can release all of these special packages, but usually other people handle that, for example, Plone Theme, Barcelona Net, and also Plone Static Resources. That's usually handled by, yeah, Peter Holtz is not doing that much anymore,

but Peyton Mathes or Johannes Rackham or Mark Dierstappen, they're doing a lot with, this is real classic UI related. They know a bit more like, oh, yeah, wait, there's still some pull requests to merge or there's a problem that we still need to fix. And okay, we'll release these three packages together. They know more about that. So I just

ask them like, hey, can you make a release within the next few days? Do they handle that? Same for, yeah, Plone Rest API and sometimes Plone Photo. That's Timo Stollerwerk who usually does the releases. I can also do that if needed. And Plone and Placala is always handled by

Michael Laria-Tegi. I hope I'm pronouncing his name right. There's also organization. That's easy. Michael and the whole Cloud Syntax team is going to end with other help in the community.

You also mentioned Jill helping you with making releases and things. I should also mention that from our first step, Jenkins, Jill has been our master of Jenkins for many years already and maintaining that and also now helping with what I just said with this unit. And to plug that right away, we also, we did have, we are in the process now of setting up a new CI team again. I mean,

there's a lot of spread responsibilities as you see, because you as the release manager have your hand in everything. I'm from sysadmin helping a bit now and there with things and keeping servers running. Jill has been doing a lot of CI teams set up and keeping Jenkins running, because if we don't have Jenkins, we don't know what the quality of the status of the software is at the

moment. And so this is, yeah, we're still in movement here and trying to also to set up a new CI team again to keep it maintained, but also to spread the load. And as you can see here now, they're like also for this already, I see like five or six people already that help you

with making also those releases. So we have also special packages done. We have Plone Theme Bus Luneta for the backend theme. We have static resources mockup, which is a kind of too single unity because the mockup things contain the source for all our patterns in classic UI, and they get distilled into distribution files and static resources. Plone REST API is very important

for Volto because Plone REST API is the gateway for the Plone 6 repo frontend. It uses exclusively Plone REST API. And to add something else that I know, Plone App Localis, everybody can contribute

to that. And it's also the contribution guidelines there are a bit more relaxed because Plone App Localis is not in the Plone organization on GitHub, but it's in the collective of GitHub. So it's easier for people to contribute there. Yeah. So basically all packages here, they are released to

PyPI.org, the Python package index, but there are some with Plone Team Bus Luneta that's partially Python package but also an npm package. So that's being released to npm.js.org.com. I never, I just let my browser figure out what that was. And mockup, that's pure JavaScript

that's also uploaded to npm. The rest is all Python. There's JavaScript and everything everywhere probably. But yeah, they're all uploaded to a Python package index. Yeah, the next item or sub item, release Plone App Upgrade and Plone Package Yourself.

Yourself being you. No, yeah, that would be me. For your readers, no, you're yourself is our release manager. That's you. Yeah. Yeah. I'm going to just quickly run one small script that I have before making the release.

I do want to do a git pull basically everywhere. I've got three or a bit more checkouts of the Plone Core development built out. One in a directory 5.2 that uses the 5.2 branch

on Python 2. I've got the Py3 which is using Plone 5.2 on Python 3. And I've got 6.0, obviously, yeah, the 6.0 branch, also Python 3, probably 3.11 locally. But in all those, I also have a checkout within the Plone 6.0 directory. I also have a checkout

of the 5.2 branch. I need to keep that up to date here, because when I release a package where the master branch or main branch is used in both 5.2 and 6.0 and I create a release, then we have the Plone release package that wrapper around says, that takes care of updating

both the versions in the 6.0 branch and on the 5.2 branch. And for that to work, the 5.2 branch in here needs to be up to date. Otherwise it won't work. So at least I know this is up to date.

Yeah. You have a question? This is also, I think, because we still share some packages, of course, but the same version numbers between Plone 5.2 and 6.0. That's also why you're doing this, right? Yeah, exactly. For example, now we'll get checkout 5.2 in here.

We're prepped for master in the sources DFT. There are still 49 packages that use the master version apparently. Some are, for example, products that archetypes, which is not used at all in Plone 6 anymore. So the overlap is a bit less, but there are still enough packages that use the

same version in 5.2 and 6.0. Yeah, because as soon as we have a package that gets updated for Plone 6 and it breaks, it's semantic versioning, there's an incompatible change, then you need to make a new major release of that sub package. And then the new major release goes to Plone 6 and the

older version, the older major version range gets used to Plone 5.2 and then they kind of get separated. But these are still almost 50 packages we share. Yeah. Or, well, yeah, a bit less, like I said, some are Python 2. But yeah, there are still some, yeah.

So I'm going to usually open a new tab. I've got that here already. Make that a bit bigger. Yeah, what we said we wanted to release Plone upgrades. I've got a small script, Plone check.sh. I'm going to run a quick version of that. Just a few small checks that are usually

run before I do anything. Scroll a bit up. I've got a versions directory with all the versions files of Plone from 4.0.0 onwards. Okay, Plone 4.0.0, we were using Plone upgrades

version 1.0 apparently. And it's just a quick check for me that I quickly see, like, okay, hey, which version is used in which Plone version? Most important being, hey, what was used in the previous Plone 6 release and in, yeah, previous Plone 5.2.9 release, but it's sorted alphabetically.

So yeah, but yeah, I can look that up. Like, okay, a bit more important. Okay, in Plone 6.0, we are using the master branch. But in Plone 5.2, we are using the 2.x branch, which means that, okay, I'm rendering the master branch now. That's only going to go into Plone 5.2. So I don't have

to check anything specific there. Yeah, maybe we should explain a bit more later about what Plone upgrade really does, because that's a bit of a special package, of course.

Yeah, some migration code in there. That's the short version of it. Yeah, we have a bit of a delay on the line, so we're kind of interrupting. So Plone upgrade contains central concrete, all the upgrade steps. So when you make, for, again, for example, we're going to make a new release package that needs an upgrade step run,

and the package is not doing it, can do it itself, but we also have a centralized Plone, which is Plone upgrade, our package, where we have all our generative upgrade step and other things that need to be done. And that's also, I think, why you do this at the end, because it doesn't make sense to update a Plone upgrade with all the exact versions from N2, when later on you release

another package that also might do only some upgrade stuff. And weren't we sharing Plone upgrade also between Plone versions earlier? We were sharing it yet, but yes, I think the version that's used in Plone, well, we can look that up if I scroll up a bit. So the branch2.x

is used in Plone 5.2, up until, well, I see version 201 being used in Plone 4.07. So the latest version of Plone upgrade is probably usable on Plone 5.0 as well.

So those are shared mostly because here that's the branch2.x that still contains all the code to upgrade your site from Plone 4.0 till Plone 5.2. And for Plone 6, that is totally useless, because if you want to migrate from Plone 4.0, you first have to upgrade to Plone 5.2

on Python 2, then upgrade 5.2 to Python 3, and only then can you migrate to Plone 6. So there's all, so on the master branch here, we only need to support upgrades from Plone 5.2 onwards.

So all the older, all the code has been removed from there, which is a lot. So this is much smaller. But it did indeed provide in the Plone 5 series that you could easily upgrade from Plone 5.06 to Plone 5.1.7, because all the upgrade steps were there in from both 5.0 to the 5.1

series. Yeah. So I'm running down the query, and that shows me, hey, if I create a release, well, the version is TBD to be determined. This is how the change log would be updated.

It's just a quick check for me, hey, does that look correct? Or do I see weird errors in here? Also a small thing I'm using, this is command line tool GH, stands for GitHub, the tool developed

by GitHub, I think just installed with brew on my Mac in this case. Just created a small list of, hey, are there any open pull requests on GitHub that I need to know about? Oh, wait, one day ago, someone created a pull request, and oh, yeah, I need, I want that in, I want to merge that first.

In this case, fool, if you're listening, you have a pull request of about two years old that's currently not going anywhere. Maybe it should, maybe I should merge it or look at it. I don't know what that's about currently, but yeah. This is kind of extra card for you that you see,

hey, there are pull requests on here, I'm going to make the final release. Maybe there's something in there. Yeah, and if I do the non-quick version, it also gives a list of issues and some more things it does, but we won't go in there. In case everybody was wondering here,

I thought about the screen, that's 6.0.50, that's the internal Cloud App upgrade numbering. So we have an internal numbering screen, numbering scheme, that's the detection. So whenever you install Plone 6.0.4 on, for example, a Plone 6.0.2 database, then the whole generic system and Plone App upgrade machinery will see. I'm now making this up, but for example, the latest state

of the content database in every day was number 6.0.12, it sees now 6.0.50, so it needs to run all upgrade steps that are registered between those numbers. That's basically how it works. Yeah.

So we can now make the release. So I am in the core development build out, we think that there's a check out of Plone App upgrades, so I'm now going to use the within bin, we have, well, if I typed it correctly, bin slash for release. So that's just release, but then a wraparound,

a wraparound, that's the Plone release package that I mentioned. I'll just run it. Yeah, I'm going to say dash dash no input to make it run a bit quicker. I trust it. It's going to do all kinds of, yeah, do a bit some checks. It's going to, in this case, a passphrase,

because I'm signing my commit. That's just something locally, and yeah, if you've ever used SES release, this output will look familiar. Basically updates the changelog file, updates the

version number and set up PY. Let's not click anywhere. It's released to the Python index. And it updates some versions in Plone Core Dev Mega, should have done the

last quick way. So it's asking, is it okay to update the Core Dev version of CFG and the checkouts of CFG? This is, it's automatically responding, yes, go ahead. It's updating first for CFG and committing the changes, and we'll see what that does. And in the end, it's pushing the

changes to get the master branches updated. New tag is in there, and everything is done. If we look at the changes at RST, we now see, okay, version 3.04 released. Well, we're recording this on Friday, April 21st, and the new snippet is in there. And if you look in the news directory,

that's empty now. If I go one tab here, so the Core Dev built out, so you get, well, get status. Your branch is ahead of origin by one commit, so it has made one commit. So I do get show,

and see the version, it says it made the commit, Plone upgrade three or four, change the versions, CFG. In this case, for most packages, it would also update the checkout CFG, remove Plone upgrade from there. So in this case, we have said that somewhere, Mr. Roboto,

there's a list in there, like, okay, if you release Plone upgrades, or I guess it's in Plone release, or that we've said that, like, okay, yeah, we always want a check out of that, so we're not touching checkout CFG for this package. For other packages, it would remove this from there. So the next time you run bin build out, you would get the new version of that

package. If I usually make, if there are more packages in here, I make maybe ten package releases, and then wait a few minutes before I push the changes from Core Development build out, because it can take a few minutes before all the packages are really, well, they are uploaded to

the Python package index, but there can be all kinds of, not forks, but mirrors of PyPI that are not updated immediately, that can take a few minutes. So we run bin build out, and then complain, hey, I can't find Plone upgrades. I've released that, I know it's there, but it can't

find it yet. Just wait a few minutes, then push, and then it works. It's also like the index, so it needs to update its index as well. Yeah, so let's say we've released Plone upgrades, and now we've released the Plone package. It goes slightly, that's a bit of a special package,

because, can I do that, git ls files? Well, this is all the code in Plone. It's basically adding some documentation, which is probably not too interesting. I wonder what's an upgrade.txt, anyway. It's just a setup, either setup.py or setup.cfg,

as the real info. It's setup.cfg in this case. It only lists requirements, so it requires cmf-plone, that's the real core package of Plone, plus a few extra packages, like for caching,

Plone rest API is in there. If you're using Volto, then you should have Plone.volto in here. Really, I'm probably the only one who ever touches this. Maybe three times a year someone else does this. I think this was also made because then you could, for example, say, look, I don't want

to iterate, or I don't want some other packages. Of course, again, this is still built out, but pip-based installs work also fine as well. There you can say just pip install Plone, and then all the subdependencies of Plone get installed, for example. These are all the subdependencies of Plone, but you could, in theory, also say pip install product-cmf-plone,

but then you would miss out on these applications because you yourself, as a developer, would think you don't need them, but in 99% of the cases, you need those packages. Don't remember product-cmf-plone, remember Plone, the meta package. If you know what you're doing, then you can do this.

For most packages, we're using TownCry with the new snippets, but in this case, we'll use Emacs. Nothing ever happens here, so we can just do this by hand. I just copy from the previous one.

It's nice to use Emacs once in a while. We're releasing 6.04. For the Plone package, I'm never doing a release candidate, actually. I probably did that during 6.0.0. We've got RC1, RC2, et cetera, but for this, I'm always for the soft release,

the release candidate, and just nothing will change here. For this, it's not really needed. For cmf-plone, I will create a release candidate. But cmf-plone is the relation here to Plone, so that one

will get extra versions, so you can update those. Yeah, so just add the commit message, prepare 6.04. Usually adding cr-skip in here. That's CR for the continuous integration, like the Jenkins doesn't need to run on this commit. And then we can do the same. Wait, I wanted to

do quickly one Plone check, but yeah. This one is maybe that... Well, yeah, okay. Okay, I'll do the slow one.

So here is really... The plot of Crumply, like you said... Oh, the plot of Crumply, you said, oh, it's going too fast. It's doing... Within here, yeah, I'm grabbing for Plone and finding a lot, because yeah, that's a special package name. You'll see which versions, but doing a bit more. Okay,

so let's check out... What else is in there? That's interesting. Grabbing in the setup-cfg and setup-py. Hey, what are the classifiers? Okay, yeah, this is just Plone 6, and these are all the Python versions. Usually by now, these are all in order.

Looked a year ago, during release, you would see... Oh, wait, 3.11 should be in there, but it's not yet. Okay, I'll just quickly add it before I make a release. And it's okay, just enter to continue. That's a few more. What's my status? It runs pyroma, which checks your setup-py, setup-cfg. Is that okay? 10 out of 10, so that's fine.

Check manifest. Doesn't need to do much. That's automatically being run during releases as well. Just continue. We have a git log, which, yeah, there's not much happening between releases,

as you can see here. Print some URLs that I can visit if I want. And yeah, automatically opens. Yeah, this fails a bit here, automatically open, tries to read the readmeo, the text that is going to end up on PyPI. In this case, it fails because

it's in markdown, and it's not only restructure text. And my script cannot handle that, but it will be fine. So I just put here. Markdown is on PyPI, uses random markdown. Yeah, so that works fine, but in my script, it doesn't work. But yeah.

One issue opening poll, which we're ignoring here, and that should probably be somewhere else. But yeah. So I'm going to release this one, bin for release. I won't do the no inputs now.

Just do that a bit slower. I probably should have done the slower version first, but okay. That's for next time that we'll record this. So asking all kinds of questions, running pyroma here again, and check manifest to see that. Check that the release will be fine. Showing

how the changes will look. Just until, okay, commit this, starting the release. Yeah, we'll create a tag in git. And we're going to check it out, because we want to upload it to PyPI. That's a lot of feedback always here. Waiting, waiting.

Not sure why this is taking long. That should be really fast, because it hardly has any code in here. You want to upload to PyPI? Yes, please.

Next. So yeah, I always wonder why this is, it's uploaded to uploadpy.org slash legacy. And I think there's, this is the only way to upload it. You're just using the standard trying in here. But anyway, maybe people are working on something new, but

so it's in there. Are they working on a new, new, new trying upgrade? I mean, sometimes I see some news about the Python packaging group that is working on new, new stuff in need. So we want to update versions in the core.dev build out. Yes.

And then, okay, do the post release stuff. Committed. And push everything to GitHub. And that's fine again. And if we check here,

back in the core.dev build out, I've got some command line thingies here that shows a bit info automatically. Then yeah, git show. And yeah, it's changed the version CFG updated to

Plone 604. So then we can go back to the browser, release Plone upgrade and Plone yourself. Check. And yeah, update the versions of those packages in version CFG. Also for these, check, we've done that. Either by hand or automatically.

And then the last checkpoint here would be, yeah, create a release candidate, in this case of product CMF Plone. And yeah, we can do that. So we have product CMF Plone.

Run Plone check. Maybe do the quick version again. Now there's not that much going on here. Well, there is a lot of info here. And see, these are, you know, CMF Plone is one of the packages with the most changes. So in this case, only bug fixes in there.

I think I've already checked this one. And yeah, there's not much more to see here. Yeah, there are some pull requests open. But yeah, we're not. I think this is fine for release. And so we'll do the full release again.

And do the slow version, because I need to do something different here. Okay, run all the different checks again. That's when I ask for version. In this case, I want to have release candidate,

we'll type correctly, 6.0.4, release candidate 1. And from that part on, it's all boring again. Check it out again, upload it to PyPI and yeah, update the version, CFG.

This is a bit bigger, well, one megabytes almost in CMF Plone. The last one was 26 kilobytes, I think, what I saw with the previous package. Yeah. There's quite a bit more code in here. But it's in the big package. It provides a lot of stuff to the CMF. And that is done. We can check the change log.

So you'll see 6.0.4, release candidate 1. This is also in markdown format in this case. And yeah, the date of today and all the bug fixes in there.

So close this tab and go back here. Again, yeah, git show, it has updated. The version of that, actually. So I just checked here, if I now go to, I just, I just, in online local machine here, I went to PyPI and there indeed, I see Plone is still version 6.0.3, but it's a soft release.

So if you go into the real releases, you see Plone 6.0.4 there. And now after this, after the push, then you can also find product CMF Plone 6.0.4 on PyPI. Yeah, that should be on there. Do we want to, do we want to try that? Yeah, you see, show me quickly in the, in the browser, indeed.

Show people my soft release because 6.0.4 is the kind of release you can install it, but it's not showing publicly on, on PyPI.org as the latest version, because we don't want to have people install it unknowingly. Yeah, so do 6.0.3, and it does say, okay, the latest version, make it a bit bigger,

but if you go to release history, you will say, okay, you have 6.0.4 RC1, it's marked as a pre-release, which also means if you do, if you now do PIP install product CF Plone, you will get 6.0.3 and you say PIP install dash dash pre, then you will get the

release candidate because you say, okay, I do want to have pre-releases. So this is how we hide it from the real official version until it really goes live, and then you, on PyPI here, it gets re-released as a, as a, as a final release. Oh, no, sorry, you have to make it because it's still the RC1, of course, here, and we have the real 6.0.4.

Yeah, so we can put a check mark in here. So then the first part, release packages and update the versions, that part is done actually. Yeah, I've pushed that to the core development build out as well. We can open a new tab, just maybe quickly to the Plone organization,

the buildout.coredev is in there. If you look at the commits, you'll see, okay, the latest commits that I've made. Yeah.

And we go to actions, yeah, all kinds of GitHub actions are being run in here, and yeah, it's already checking some things, some basic ecosystem tests have already passed, version check, and it's doing a few more checks now. And maybe also if you go to

jenkins.plone.org, you will now see that it's starting a few jobs in here, checking, let's pick this one, Plone 6, Python 3.10, this being run, one of this is going into too much detail, if you click on, okay, you'll see some changes,

say since the last push, it has also those three commits in there. You just did, yes, for which you waited, the last push. Go to console, you see it's running all kinds of tests. Do we want to scroll up? Well, yeah, that's too much detail, but yeah, so it's starting all the tests.

Yeah, because making a release is also doing commits, and on commits, we have our test automation running, so it gets tested right away after the release as an extra save card, I would say, but it's not because it is another commit, so we test it. Also, for people, Mariusz, I was just, when you did this, I was like, can you keep the screen?

I was myself running, I've seen this, and I've not seen this so many times, but I know a bit about the principles around it, and I was wondering, how can you do that, Mariusz? You're first releasing Plone, and then later you're releasing product CMF Plone 6.04. Shouldn't the Plone, shouldn't product CMF Plone 6.04 RC1 have been mentioned in the Plone package,

but you've released that before, but I think you're going to solve that now later, because this is what is now going to happen later, and then I saw the title constraints, because you didn't actually pin Plone 6.04 RC1 in the Plone package.

That's the constraints that we're adding now later. Yeah, within the Plone package, it just says, okay, I want product CMF Plone, I don't care which version, we could add something like that, but yeah, we're currently, and we currently don't so it's really just, yeah, if you install Plone or use buildouts, then you should be using it,

I'll go to, we have this.plone.org, I'll make it a bit bigger, so I've got this.plone.org, that's just a small server, we've got here, is that download? No, that's really, we've got a few really, really, really old packages in here from 2008 or earlier,

but you have the release directory here, this is, there's all kinds of files from, from really long ago, starting with Plone 3 somewhere, if I scroll to the bottom, then, okay, so if you pip install Plone, you should always, always do, okay, pip install,

pip install Plone, and then in the dash c, and then, okay, HTTPS, this Plone org slash release slash this Plone version slash constraints txt, or if you're using buildout, you choose, okay,

versus CFT, and if you need it, versions extra and versions ecosystem, and optionally, you can use the requirements txt to create your virtual, and you can, it's fine if you use different versions of pip setup tools, whatever you want, whatever works for you, but these are used in

the core development buildout, they, the difference per version, what you also have here, we have 6.0 dash latest, that's just a same link to, currently to Plone 6.0.3,

we have 6.0 dash dev, that's actually what we're going to touch next, there are a few packages in here, which are only in here, and not on PyPI from when we're still really developing Plone, really the pre-alpha versions, basically,

that we wanted to test somehow, but these are release notes, change log, constraints txt, requirements and the versions, this is 6.0 development version, usually this is just the same versions as from 6.0.3, but I sometimes updated in between, I think really this month,

we needed a few package releases in between, I just updated a few packages, I think that may already be in the release notes, yeah, I've done some work today already,

but yeah, at least I've made a few, I've updated a few packages already in the constraints in the version cft, because we needed that for some GitHub actions somewhere, so this is currently 6.0.3 plus a few more packages, and for now we, yeah, if we go to the,

it's like weekly or nicely released directly, where you can have in between releases, yeah, so yeah, we will be updating this Plone.org, that's the first next checklist item,

and that's what you want to do, everything all in here, but yeah, we can't do, well, we can't do the final release, so today, so we'll do it, but here we're almost one hour busy already, so, but yeah, it's quite a bit what's happening, yeah, so in the core development, I've got a release-6.0 dev,

that's what's mostly what only I am touching, maybe other release manager people from release team, there's also 5.2-dev, and that's from there, I really compile the versions and the constraints,

and we can go there, get checkout, I'll base this one that I do, go back to my terminal, I do it in, I built in two steps, so get checkout release-6.0-dev,

if you look here, this is almost the same as 6.0, but if you look at the checkouts, it's basically empty, there are no checkouts, it's 5.1 been built in here, then it's really using the latest product, CMFPLONER release, although currently, well, if you search for

CMFPLON in version CFG, and let me, yeah, just keep it there, so it's 6.03, we want to change that to now 0.26.4 RC1, basically what to do is, this one, I want to take over all the changes that have been done on the 6.0 branch,

and take over the relevant changes for me, so it's, yeah, some git magic, git reset dash dash heart 6.0, and yeah, let's just, I'm focusing on, no, I'm focusing on like, okay, I've seen this

before, but this is, this is now going a bit over my head, I hope other people can follow, or at least I have to say, git is also, I'm using the basic stuff in git, so the 6.0-dev is really this kind of intermediate staging area, to finish up the last constraints,

and other dependency files, to put it a bit more fake, yeah, so yeah, let's maybe not go into git details, but with these two commands, some git reset commands, and now I've, let's take the

status, I've got several files that have changes compared to the real 6.0 branch, I can ignore most of the changes that checkout.package ignores, that's something that's, well, that you can ignore, I really want to ignore everything that's happened in checkout

cfg on the 6.0 branch, because we don't want any checkouts, the last commit, that's something from Mr. Roboto that we can ignore, so that's a bit less, and I know, yeah, within here I have been working on the release directory, so I've already updated the release notes a bit,

so the release notes that are in the release 6.0-dev directory are more current than what's in the 6.0 branch, so I'm also ignoring that, the only change currently is versions cfg, and I've already done this this morning, so really the only changes currently are, yeah,

just the three versions that you updated a few minutes ago, so Plone, PloneUpUpgrade, and CMakePlone, yeah, that's what we're going to work on coming in, yeah, and the RC worm now.

Yeah, so this is the final, the final versions list, the pinning list for our packages for for CodePlone. Yeah, so quickly go back to the checklists, yeah, I'm going to check that, I haven't committed it yet, but I will do that together with another one, so yeah, when I work on, okay, updating

the disk.plone.org directory and preparing some files from that, I've got a file, I'm using TOX for that, let's do that one, okay, maybe.

be quickly okay call all this something okay don't do what don't do whatever is in here but I wanted to quickly show what is in here so the release we show a bit more like an hour more it's we don't have to stick with our if you have some more minutes that's fine I also want to show a bit about the containers I think at the end I didn't I didn't know the other parts were awful he oh

yeah sure sure and I can ask some questions about it but now the last one for you to begin with it on the death branch is somebody like okay I understand the end result again but that's called constraints generation and

things are interesting and that's why you are doing this and not and not me yes in all kinds of flow packages for using talks to run tests and also run some linting but you can do all kinds of things with that so in the release directory you've got talks.ed with well with four constraints environments for

for each for four different Python versions and so for example for Python 3.8 we're running up I've got to create constraints.py commands or

within the release directory that does all kinds of things it checks only the ecosystem probably bit more at least it checks the version CFG and not sure why

this exactly is I think ecosystem CFG that's also contains for so I think that checks out everything that's the normal core development built out checks out to all the version pins plus a few extra that's it indeed for for example Plunar Mosaic is in there plun.tiles so creating constraints based on the

ecosystem versions this gets over the version CFG and all other versions and in the end compiles that into a constraints file specific to Python 3.8 because I'm running this with Python 3.8 as a Python version it's probably too

and you're running the same the same commands with Python 3.9 3.10 and 3d at 11 yes we could be small differences between what you've been apart and 3.8 until 3.11 that's of course a bit more on the plot on plan 5.2 where you

have the same thing they really have yeah for Python 2 and Python 3 that can really differ a lot in there so there you really need it here it's not that much yeah our breaking change our kind of watershed release between come from

Python 2 7 to Python 3 so fun party can still run both in Python 2 and then you have this this opens when the constraints for Python 2 7 can be different from from Python 3 but now I mean the Python software has sped up

the clone 3 alone with the Python 3 releases to a much more strict release schedule but then in between releases that they're more incremental I mean we're all cheering about Python 3 11 because of the nice speed increases but it's unique Python 3 8 to 3 9 to 3 10 it's all medium to smaller improvements

and there's nothing really breaking changes between the fighting three releases yeah so we're creating a those constraints files and then another one that's called combined constraints combine all those into one constraints

of txt which we'll see what's the end result there is and then we have environment gather which is gathers everything from a few spots in the core development built out to the release like this directory and we'll just

quickly check that released as this I've already run that today it's in there so these are the files that it's gathers from a few a few spots in the core development build out so are really in yeah everything is in commit in get

actually but you were copying the requirements files the versions files the constraints files that we've just generated so okay you don't look look in a constraints file for example we have to I will create a constraint file now

we've talked okay let's do that first and there will see the difference so it's running yet saying a bit too much simply say constraints real dates has worked okay and then constraints running constraints three nine etc so okay everything has worked then three now yeah with mine see that two files have

changed so we had a change in version CFG that wasn't committed yet and I was with a constraint see if txt so if you look at release constraints txt that has now parsed the version CFG and the other files and said okay we've got

blown 604 CMF plumber lease candidates that's blown up a crater is in there mm-hmm and these are these contain folder and to explain what urgency and we have constraints txt versions are our first level packages that we bet you can

depend on and constraints txt also includes bennings for dependencies of dependencies yeah I'll just commit what I have here need a password here yeah committed to this change yeah if you look quickly or the release directory so

yeah the constraints txt that's what's combined so everything look at constraints three nine three ten eleven that's exactly the same or at least it's theoretically there can be difference but I know there's not there's a high chance for three eight there's a small difference if we just compare here

constraints three three eight txt with constraints three nine dot txt created by so for you know the three nine txt is missing two pins apparently in the

version CFG somewhere could also be somewhere in the soap versions there's a look something like this versions parts entry 8 will be somewhere in a version CFG that says okay want to pin backport zone info and package it to resolve

naming those apparently packages are only needed only put in or parts and creates so that's the only part of version that actually needs these pins and on parts a tree now we're just not spinning it in this case it would also pay attention but you don't really know that's beforehand it can be the part of

three now needs a newer version of one of these packages especially with Python 2 & 3 if you still be using that 4.5 to there will be lots of differences well hey on plum on Python 2 we need a version 1 of a package and on Python 3 we need to version 2 of that package and otherwise things really don't work

yeah I just realized now I need for if you go to minor Python versions then you have sometimes in a new apartment version something has been solved so you also don't need a package anymore or a third-party package needs to indeed have some small adjustments and then you have a different version for that right yeah

so we've done the talks release now could also be in manager using plumb release or can have been managed change log that's the thing creating a unified change log I'll start that that can take a bit shouldn't be too many differences

because I already did this tomorrow but this most again yeah actually who did this maybe I've done some bug fixes over the years that can be but this looks in thinking over its so you say okay starts from 603 I think it looks on this

to plumb.org in the 603 the version CFD okay which versions are used there and which versions are in the curbs version CFD what's the difference then she's okay for example plan hey there's a difference in plumb upgrades okay I'll make it I think it was a real check out of plumb upgrade somewhere and looks at

the last it sees what the difference is in versions and also checks hey what's looks at a change changes dot RST or that it doesn't look at the markdown files yet you have to fix that at some point but it's gathers all the changes

between those versions into one file which is yeah I'm just piping it to there this was a bit faster this morning but you know we're live recording here and this is how you get the really detailed change logs that I link to from

the news item once the releases yeah so we've got it so it's parsing all kinds of things think this is life updated here it's still busy yeah yeah that can

take a while it has seen that okay all these packages have new versions and it's discovering a few more as we go like a seem of blown he doesn't know the changes of C of blown because it changes dots MD is not it's not looking for that yet so that's something for me to fix at some point and now it's okay like bit

we've updated PIP to 2301 yet it doesn't know how to think it's only really adding the details changes from new clone packages yeah yeah we're using this version and it's no breaking change wait what

there's a breaking change in clone 604 yeah the breaking changes that we drop by to support so for clone 6 that's totally not interesting it's not breaking anything so that can be a bit where there are lots of breaking

changes in here that aren't are not really breaking anything for plus six itself let me check if this is finished yet it's finished and I'll quickly go to the top because here I'm always removing this part because it's not interesting

let me change this check the diff and yeah so it's no detected okay yeah there's a new problem release six up six oh four yeah there's nothing happening there but location was also one with markdown where this morning already

added this and it doesn't see it now they are need to fix that yeah fix spending our thank you do you forget over fixing spending our okay that's simple upgrading your release and yet seem of clone that's again that we have to fix say the markdown is not recognized so I'm going to

checking over how do it we do that again get at this dispatch test was I was

looking for I want to yes I want this change this is just because I do not want this change just cherry-picking some changes here this is fine here I think we're this yes so gets checkouts so yeah so these are the

changes in here yeah so this was what I've already put in there manually in this case this morning and keeping it at 604 not an RC one because then I will

forget to update its next Monday or something so obvious do that in here but it's the so it is it's change log yeah yeah quickly back to the checklist that was done okay after

release notes dot markdown file that's in here I've why is seeing a change in my editor this quickly check but this is nothing to fix okay that's just so go to

the release notes for any updated that a bit this morning sale of release candidate one updated today there are some standard links in here currently

I'm already pointing to the release six that's your death on this to pull the dork because release in there yeah so this is the soft release and it's for the final release it will be 6.04 in there pointed to the constraints and versions files and yeah this is something do manually some major changes

in 603 that would be for the plan usual maybe to discuss what's in here but this morning it's done this this morning already we can look at that but yeah

maybe yeah just done that in here what's in there for the front end I've checked already today hey what's the latest photo release from the photo 16 branch that's 16.4 from think that was yesterday so we're looking there and

documentation very nothing you okay the Python compatibility 3823 that 11 I've ready updated or just based on the requirements TxD in here so people know okay these versions of they've been set up to us and friends worked for us but

oh yeah feel free to use whatever version works for you yeah but these are tested and we know that these creates and functioning set up and they have been I mean that we've have I mean people still being developed the whole

packaging infrastructure is being developed and sometimes we have these really weird edge cases with with slightly different tips I mean it has also taken a while now to get to if 23 because we were stuck on 22 also for a while because I'm so mad sketches if I understood you correctly the last month yeah that's done some pull requests on bit and set the tools the past year and

things were fixed and yeah for example set of tools 66 or higher that's more strict in a versions I think if you try to use it up to 66 or 67 on plow 5 to 11 that it will actually fail to install because because of some stuff that are

in the set of PY of CMF plumb 5 to 11 that this will be fixed in the five to twelve and it's trying some some pre-development version of a package is stated as a minimum version and that's just not working with this at the tools

version so it's great if you run into those kind of problems you may just want to use set up to 65 or earlier but plumb 4 and plumb 6 work fine here yes but if you think why why all this difficult stuff with constraints and other things

this is why because the small the small infrastructure packages like providing the installation features do have to do tend to have sometimes some small bugs or things and at that time then we checked it everything was green that is how it works please use those yeah exactly like if you just create a new

virtual environment and go okay just to pip install plumb then it might work but it also might not so you should always do okay they see for constraints and then okay this is a really long list of constraints that we know work together

and that's because we've been creating now yeah yeah so I didn't change anything to the release notes because I did that this morning already back to our checklist okay release notes are done get the version CFG well that's all

things are gathered with the talks file so that's done create constraints txt yeah we did that sister the talks thingy yeah check it and I copy those to the pending release directory the six year old F staff directory that's what we'll

do now but yeah we I do want to do that fun again and do that a bit quicker by using multiple threads because the constraints haven't changed since a few minutes ago but we did change the change log so that's that's gathered now as

well so it really is like this here are the newest files in there so this is the magic the magic set up in deep pinnings and versions that that that really say this is the next one release yeah so I secure copy just everything to this

blog.org and now everyone knows how this yeah just copy it over there yeah I can SSH in there but yeah you'll believe me let's push these changes to get up by

now actually so now this to plan.org is has been updated so check this and check this and yeah let's quickly check this.plan.org go to down 6.0-dev and

yeah well yeah let's check constraints.txt look for yes product.cmf

6.04-rc1 so we have updated to it so that has worked so we're almost there we just need to write a post on community.plan.org I think we can do that live

I think I've prepared small bits of that already Oh where am I yeah community.plan.org open a draft so plan 6.04 soft release put it in announcements 6.04 has been soft release time yeah this is some

standard stuff that I copy let's go to my browser copy based release notes that's in markdown just paste it over there escape this one yeah so if the

release notes and the markdown has worked and highlights and everything and this is what we saw way to the links were just checking the constraints file just quickly open that and also the versions file check the depth yeah that

looks yeah seem of clone 6.04 that works and we have CMF blown in a version so yeah 6.04-rc1 we have to write links that's always fine so yeah great topic

and publish and we're live and people will see this hopefully next week and then realize that one Friday late they saw it maybe there that is the community.plan.org and also saw the news item yep yeah so write a post and wait

for feedback preferably be at most a few days so if you're watching this video well you're hopefully probably we go nuts because yeah it will have it you will have tested it thank you very much for those who did it's probably at plan

usually next Monday I'll really make the final release mm-hmm yeah we can quickly look at that because yeah that's in here as well of course so what yeah what to do then yeah make a fire go to you if nothing serious comes up that

needs a bug fix then I just go to product CMF clone and can make a new release on PyPI but then just go to 6.04 the updates the version CFG again run on the 6.0 dev branch make sure that's updated and with the constraints txt maybe check after release notes yeah change a few links in the release notes

I always create a tag of the 6.0 dev branch so there's a 6.03 tag already and so I'll create a 6.04 at that point push that on this plumb.org created or just make make dear 6.04 and put the constraints etc in there and there's

also a sick make sure six that's your dash latest points to 6.04 yeah notify Erica or or me information president or or notify threats or anyone else yeah installed it or usually I use the release team discord channel like hey

hello there's a new release can you make Docker images I think that's just changing a few numbers in I can do you need anything for the screen share

I'll share my screen and you can close it yeah maybe do this is important it's not only the software there's some other useful things in here yeah so create a

release page on download releases currently I need to do the plot org uses photo but for this I actually need classic UI but yeah that's something to be fixed think it mostly works but I've prepared some we can quickly look at

that see I should can I log in how do I look in quickly login with github that works and go to yeah hey on the front page 26 April 2023 that's today if you're watching live hello releases yeah it's the announcement I know this is

download releases place 6.0.4 that's all right I've already created that afraid at all yeah I won't edit it now with updates yeah this is mostly what

was I think that's already fine maybe the constraints need to be updated so that's prepared and so yeah it's still private so we can't view it the next Monday I'll just publish it so that's prepared say hello to the marketing

team so they can prepare announcements they can for example Fred's will do that's we have a news item then we create a news item it's always on the home page as well so then people can very quickly from the home page see that there's also a new plan released and that will what I'll do together with you or another person from the marketing team will will see at your

detail change log pick up and discuss also ask people beforehand hey which are the biggest ones which are also maybe users facing or are really also small functional improvements and then we'll list the biggest ones in the news item yeah there's a security page that needs to be updated that's some things

in the registry that need updating for that and and some manual stuff currently because those need to be with the updated plan or some more stuff needs to happen a bit but yeah well updates other to the security page basically saying that's okay a six or four is supported with security updates and it's

maintained and that page is updated publish the release page update the release schedule everyone should know a bit by hands the release schedule yeah they're mostly just updates the you scroll down 604 that needs to be a bit

bigger sorry for the flashes I've currently 603 or change that to 604 over there the next release expected I will say there may 23 because yeah expects one every month

yeah well for link we need to edit and then announce it but much like I've announced the release of now the final release and one thing I need to add here that's okay being Steve Pierce he said he can update the documentation there's also a link in there I think mostly from the installation documentation that you

copy some command that you ultimately have 604 in there it works yeah so that's it for me with screen sharing I think so that's yeah I'll quickly show for to be just a complete yeah yeah how we are going to make so stops I'll stop

sharing my screen I am then I can share it the software is helping me to avoid any blonde it's smart okay it's smart indeed so to show a bit more about

because now you have the whole release everything is there everything is on this top loan dot org we have a separate repository in the plan organization blown back end and what we need to do here this is helping us to build the containers we are using Docker files and we're using GitHub workflows to to build

this but of course as you see here the last it's bigger maybe yeah maybe a bit bigger like this that can probably help yeah so as you can see here for example somebody here and I think this it was you know that's a little so what you see here last week was used on 603 and this is basically the commit where we say look update this repository you see it's only in two places where we say now use

the 604 versions and then for the rest it's almost done automatically by a lot of automation in GitHub workflows where we create images and this is not only run for the releases also run for nightlies for example and this is building the blown back ends so this is the indeed the plan back and content

Apple server and also classic UI there's a different proposal in front end which does the same thing but then for the whole photo front end and here you can see for example under the actions you can see that we have nightly images which are built every night and if I go further back you'll see that there should be a 603 somewhere yeah you see so it was three weeks ago when we had

planned 603 and that generates and uploads all our images to help the doctor calm but this is the step that's that's when you are done with everything here and we have those blown release files all there then it's a separate step to build a kind of mini runtime environment which is the container image

in which plan also runs and then you can start using a clone 604 also through containers so now it's one hour 31 and a half hours that's a lot of work

merits and you do all and you kind of spoiled it by telling us already did a lot of work this morning so it's actually more like two two and a half hours that it makes you to do this so almost it's almost longer than the clone you so it's almost longer yeah we can just get about it but it's needed to see how I'm happy that I was able to get you to show this to people for once I

mean don't show you don't have to show it every release I mean you have people that that I think it's fun to record themselves while they develop all day

it's also everybody but thank you so much for doing this yeah and next to plug 605 but that's neat so you're planning to release this somewhere next week if nothing comes in then we'll have somewhere during the week we'll have to plug 604 final but then of course if people see this on world long day then

it might already be there or it there might be some some hiccup and then it will probably be released next week yeah hopefully Monday 24th it will be released I hope so usually that work there haven't been many problems lately

with at least not with the bug fix releases that's yes we're stable now yeah yeah it's a real major release then you take of course more time and then we also we don't have just one release candidate that we have also better versions after I mean we have a sprint coming up in May and we've already had a big experience in in February so whenever a plug six one is ready then

you're not doing this just once then you have will have multiple better releases as well where this is happening but that's something for in a few months so merits thank you so much thank you for viewing a happy continuation of will

plunder I have no idea when this call is scheduled during the day thank you so much more for showing us a bit like we say in Dutch for a show in the kitchen of making plan releases and enjoy the rest of the world one day so yeah that's my works for race our news manager have a nice day bye bye bye