Version 16 (and later 17) development considerations

Questions
1

So this is an open ended question with no right or wrong answer. My idea is this is more a discussion piece…

When planning projects to be started in the next few months and completed shortly after the release of LTS v17, I’m naturally considering the possibility of developing in v16 with an upgrade to 17 towards the end of the development process and then launching a site in the new LTS version

The biggest potential issue I can immediately see with a straight forward site is how to handle those custom pickers that we would currently use Contentment for, but I’m sure there may be other things to think about too.

Is anyone else thinking on these lines? I would love to hear any thoughts and opinions as to why a 16/17 development might be a great idea now, or equally, a stupid idea.

Are there any issues others can see being a problem for early adoption?

2

It really depends.

For new projects, we would usually just take the LTS version, but there comes a moment where it doesn’t make sense to start a new project in such an ‘old’ version anymore. If a clients need to be paying again for a serious upgrade within a short period after their new website is released (in Umbraco 13), it doesn’t make sense. So around Umbraco 15.2, we would start new projects in Umbraco 15 instead of Umbraco 13.

For existing projects, we would give the client the option: have the stability and less upgrades or have the latest features. Our private packages have the same support as Umbraco, so new features only come to the latest version of the packages. But most of them remain on Umbraco 13 and will be upgraded to 17 when it’s out.

Having said that, it depends if you have a lot of customizations to Umbraco. Upgrading the backend stuff from Umbraco 13 to 16 (and probably 17), like APIs, composers, indexes etc isn’t that hard. Yeah there are some caveats and changes, but most of it, is not that hard.

Backoffice changes however have changed massively and have quite a leaning curve. I think the new backoffice in combination with the management API is absolutely brilliant and very future proof, but it takes quite some time to lean. So in that sense, I suggest you start investing in the knowlegde now. I don’t expect Umbraco 17 to have massive changes over 16.

And speaking of Umbraco 16, I think it’s really in a good place. Umbraco 14 was new, but Umbraco 15 has been great to work with so far, getting better with each minor. 16 is just the next improvement, but really not that much different than 15. I would absolutely have no issues starting a new project with Umbraco 16 (although I would usually wait for 16.1, just in case there are some big bugs).

For existing projects, if there is no immediate reason, I’d just wait for 17. After 17 comes out, you still have a year to upgrade from 13. But get into leaning 14+ now :slight_smile:

1 Like
3

Contrary to what I think would be the popular opinion, I wouldn’t go to v16 now aiming to upgrade to v17 later for the following reasons:

  1. Clients won’t probably accept to pay for the upgrade later, especially if they are not tech-savvy, meaning that developing for v16 will just add effort on our side increasing the total cost of creating the website.

  2. Experience has shown that there WILL be breaking changes, hopefully minor, but not always the case.

  3. Even when it’s on v17, I would wait for at least one or two minors before I decided to switch to that new LTS. Again, experience has shown that, even when not intended, there might be some annoying bugs and/or breaking changes during early versions of a new major.

  4. Some third party packages will be ready after a while, but not before v17 is released. Developing in v16 means that I can’t be sure about which packages will be available and which won’t. Many package developers prefer to release packages for LTS versions only (including myself :slight_smile: )

Of course, if it is the client’s demand to go to v16, being fully aware that they’ll have to upgrade soon, it’s a whole other story, and I’d gladly do it.

1 Like
4

Pretty much echoing Luuk here; I’m not a fan of jumping on STS, but having tested the 16 RCs I believe that it is in a good place to start production based projects. There are a few things that I like to consider:

  • Do you need to do any custom back office work? This has been re-written with new concepts and ways to build, so if you need to do custom back office work then give yourself a window to learn the new structure. You’ll have to learn it at some point; right!
  • What packages do you actually need? Contentment, uSync and Skybrud Redirects all have working versions in the new back office.
  • Updates to the new back office may be a tad inconvenient as they will happen, but it’s unlikely that they will be big hairy changes that need a lot of work to update from our side.
  • Upgrading from 16 > 17 will (in theory) be an incredibly simple upgrade. 13 > 17 could be more complicated.

Ultimately you’re going to want to move on from 13 by Nov 2026 for EOL so an update is innevitable, 16 is stable and has good support from a package perspective.

1 Like
5

Thanks Luuk, I can see now some really good points here that echo my thought process on timing for a new build. I’m the same and normally just take the current LTS as the starting point. But in this case I can see that v13 will be the LTS when we start the build and by launch it will be v17.

Back office customisations will be minimal for the project I am thinking of and therefore the the learning curve should be short too, but the time impact on that learning does need to be taken into account. Thanks for sharing such a comprehensive reply, it gives me more to think about

6

Hi Sotiris,

Thanks so much for your thoughts and welcome to the new forum!

  1. Not a problem in my particular case as a v13 build would also need an update to v17 within a year of launch and this would be expected by the client, and also in this case the v17 update would be pre site launch. But this is a very valid point in general and is also the reason I would normally build in LTS versions only so as to minimise the frequency of updates and to extend the duration of each update window.

  2. My expectation is that the v14 and v15 would have had the bulk of the breaking changes from v13 and that v16 to v17 breaking changes should be minimal. But I absolutely agree there will definitely be some!

  3. This is a really good point. The first few minors of any LTS version can be problematic, I need to give this more weight in my considerations, Thanks for the reminder!

  4. Again a really good point, In my question I mentioned that Contentment would be missed in a new 16/17 build, If we wait until v13 EOL is getting closer for the v13 to v17 upgrade then that problem may well be resolved by then.

Thanks Sotiris, some really helpful points here for my particular case. Hopefully this is useful for anyone else making a similar decision too

1 Like
7

Thanks Richard,

  • I’m expecting any custom back office work to be very minimal, so this echos my thinking
  • Ah! I’d just looked at the umbraco marketplace which listed contentment as v8-13. I’d overlooked the pre-release versions. That’s excellent news and yes that is pretty much exactly the expect package stack!
  • Yes that was my thinking too
  • This was exactly where I was coming from initially!

Some really great points, Thanks @Rockerby, @sotirisf , @LuukPeters and hopefully useful to others too!

2 Likes
8

re: Contentment for v16, I’ve been posting status updates on the GitHub repo.
TL;DR, It’s all pretty much done apart from the Content Blocks editor, which I’m in complete limbo with.

1 Like
9

Also, important to note is that usually the breaking changes aren’t as big. We’ve had two very big changes so far:

  • Umbraco 8 to 9, backend framework change
  • Umbraco 13 to 14, frontend framework change

All updates from 9 to 13 and 14 to 16 weren’t that big an fairly easily done. Sure, you need to plan for the fact that major changes can happen, but in reality, usually it’s well known in advance what these changes are going to be.

So we don’t have strict rules about only using LTS or STS. But based on the changes we can make decisions based on if we’re ready to go ahead with a new version or not. We skipped 14 entirely and started updating internal packages when 15 was about. And I can imagine that we have major changes in the future, we might also wait a little for it to mature a little.

The point is, unless there is a good reason not to, using STS versions usually isn’t THAT big of a deal and Umbraco 14+ is an exception when it comes to very big changes.

1 Like
10

Thats awesome Lee, I think I knew already that you’d got the bulk of it done, must have been having a forgetful moment!

I’m afraid I’ve never used the Contentment Content Block Editor, for me it’s all those pickers that we can link to any source with C# code that is the killer feature we just couldn’t live with out.

#H5YR mate