Can anyone fill me in on what the philosphy is for Umbraco for when something is alpha, beta and Release Candidate? It's not a jab at anyone, but for me personally it feels wildly inappropriate to give something the state of release candiate while core functionality is missing. We're on RC2 of Umbraco 14 and you can still not add a blocklist or blockgrid and get your content all the way out to a view, and I can click several places in the backoffice and get a "Not implemented" alert. To quote this blogpost (https://umbraco.com/blog/umbraco-14-release-candidate/) "This release is broadly speaking feature complete" This feels like a bold claim when I can't use blocklist, blockgrid, webhooks, none of the default data-types are available unless you yourself open them and hit save, and preview, a -dare I say- core functionality of the CMS won't even be available on release? Everyone is doing a fantastic job on Umbraco and 14 especially, and I'm very excited for the modern backoffice and full of appreciation for anyone working on it, but the release labeling feels like it's decided by a calendar and not the state of the product and it is very hard to explain that even though it's the -second- release candidate, it is by no means near being ready for release.

Hey @Kaspar Boel Kjeldsen, I feel your pain here. I've got no special insight to share, except to highlight a couple of things from the blog post you linked. Versioning has been driven more by the state of the Backoffice APIs than the completeness of the Backoffice UI. > The focus is on providing a good base experience of working with the new Backoffice and APIs > This RC is a great opportunity for package developers to get started. We’ll minimize breaking changes from now on, and it’s safe to get started upgrading packages. But, as mentioned, we’ve updated a lot with this release. I think the above points, from here: https://umbraco.com/blog/umbraco-14-release-candidate#known, kind of sums that up. In various presentations on the new Backoffice HQ have pointed out that v14 is ready for developers to start building Backoffice integrations on, but not for building sites with yet. Can I ask, if you haven't already, to flag any bugs you find on the issue tracker: https://github.com/umbraco/Umbraco-CMS

@Jason I'd also argue the state of the Backoffice doesn't warrent a Release Candidate label.. Like... I can click several places and get a plain old javascript alert stating it's not implemented yet. When your packages depend on for instance blockgrid and blocklist to work, it's hard to upgrade them 🙂

Yeah I agree, it's not RC quality. I forgot to say, regarding your calendar point, Umbraco releases are totally governed by calendar. RC release dates are fixed, like major releases, so it goes out in whatever state it's in at that point. That approach works great for the usual incremental development of Umbraco but not so much for a big bang release that's changing most of Umbraco's code. Umbraco is really wedded to that release cadence. For better, or worse, it seems.

The key thing with the release cadence is that V14 will be released on May 30th, but won't necessarily include the new backoffice if it isn't releasable, by being date driven you get the predictability of releases and version numbering.. and in order to meet that commitment you cut the cloth of the release to suit. The problem in the past is that release dates were arbitrarily held back until it was 'arbitrarily' ready.. when is V8 out? or things were just released randomly, and hoped to be ready sometimes to coincide with Codegarden Keynote! and then immediately patched, nobody could put time aside to help with an RC, because they didnt' know when it would be available... The benefits of the predictable release cadence is when it is released it has gone through these various steps of testing and community involvement to ensure quality. Package devs have matching releases ready. An it's been great to start a project on an RC knowing the final version will be released before the project go live and we don't have to wait for the .2 release in order to get a stable version!

These are all good points until you factor the big-bang nature of the new backoffice into the mix. > but won't necessarily include the new backoffice if it isn't releasable We know that v14 is launching feature-incomplete. There are features that will not exist in 14.0 that do exist in 13.3. Also, there is no releasable "v14" branch of Umbraco that doesn't include the new Backoffice right now.

I think the main issue here is naming. None of these are "release candidates" - namely, candidates for releasing. You can't really release RCs to a schedule. This naming is dangerous to Umbraco's reputation. They're alphas, feature-incomplete betas or "previews" (At least I hope these aren't genuine candidates for releasing!)

I think Marcs point is correct, and how they have handled releases after moving on to the fixed cadence. However, it looks like they are committing to the unfinished backoffice for v14 despite the underlying idea behind the fixed cadence is that things should be cut if they are not ready and then pushed to the next major. Just like they did with the new backoffice for v13.. I don't have a good overview of how close it is to finished though, and maybe they will in fact make it for the targeted release date. But I must admit it worries me to see things like preview not being implemented, or block editors not working fully at this point!

Edited: just too negative and I don’t want to be like that.

@marcemarc like @Jason is saying, there is (at least not anywhere I can find on the repo) no version of 14 without the new backoffice. Which is why the do-or-die we release the 30th of May sounds so scary, when you've tried version 14 as is. None of the release candidates have been anywhere close to a state you can call ready for release - which isn't a jab at all the extremely talented people working on this, but why I'm asking questions about the versioning philosphy, because it does not make sense I think. Especially in communication to people "out of the circle". We've previously launched a (admittedly small) website on an RC2 because we wanted the content delivery api, and having to explain to the same Client Manager now that -no- we cannot recommend v14 as something you can target for the next project because of the state is in, is very confusing communication.

@Kaspar Boel Kjeldsen sorry I'm not trying to say that is what is going to happen, was broadly singing up the benefits of the fixed release cadence, and how that strategy can still handle major releases and still align with customers expectations and the versioning philosophy as a whole - Umbraco isn't a tiny operation anymore where a few devs are frantically hacking together the major release a couple of days before Codegarden, there are lots of business have bought into this stable release cadence and the quality of releases as a result. It's a great selling point. Speaking completely hypothetically to illustrate the release cadence approach, the V14 release without any new functionality could still be an important stepping stone release for consumers of Umbraco - if it didn't include the new backoffice, you could hide Macros, remove XPath, take out nested content and the old grid and other things that are on the list to be deprecated, this might seem counter intuitive having less features than V13, (but the new backoffice will have less features than V13!) -

I agree in principal and have myself through our work benefitted a lot from the stable release cadence and being able to count on certain milestones. That is the excact reason I'm raising concerns this time, as it feels different. This is a big bang, and it doesn't feel ready, and while I'm just going to make sure we don't base anything on Umbraco 14, except trying to upgrade packages, until it feels ready, I am also concerned about the broader story. We've had a very good streak of good solid releases and I'd hate for this one to break it because it -has- to come out the 30th.

The current state of GitHub is an onslaught of issues that pertain only to v14. The issue section looks like complete chaos right now. You'd think everything was broken overnight. I'm guilty of creating two or three until I recognized the state of v14—a completely experimental version for prototyping a complex overhaul. Some of my more technical clients ask me what's going on, prompted by all the reported technical issues. *HQ sells products and services directly to consumers. * It's not just developers who are confused by your release cadence! People who are marketing and program managers, instructional design leads, and just run-of-the-mill editors are also confused. These are the people to HQ markets its products to. Do you want to support them on this release candidate? Would you say you are ready to release this on Umbraco Cloud today? That's what "release candidate" means. When I run this version of Umbraco, I see WW3. I strongly recommend a more consumer-centric view when considering what you release "in public" and what you offer "in public". Their opinion matters the most. They do not care about your version numbers—they think bigger number, better software. Let's check Wix, Squarespace, Webflow, Shopify, and whatever else I missed. I bet they communicate version numbers to their customers... This is not a release candidate. If this version of Umbraco "hits shelves," you're going to ruin many people's first experience with Umbraco. The potential negative impact of this could be significant.

I'm seeing all your tickets - must admit I'm currently just checkin in every few days to see if any of the things I already know don't work have started working, before diving into more bugs, but yeah.. A lot of those bugs are very scary to see so close to a supposed release date.