is the default for "gulp deploy" to create a backup? We're on 2018.2 and no backups are being created when deploying core code. The backup folder doesn't exist in the ssp either.

I believe so, but the default value lives in distro.json so somebody might have turned that off? Just an idea.

I can see that backup is set to true in distro.json. That was a good thought though.

I think Kilimanjaro was the last version that automatically uploaded a backup.

I'm working on core SCA on a 19.1 (i do work on core when i have to work on extensions that have BIG ssp-libraries development, as activating would be such a waste of time... i migrate them when i finish). And i'm seeing backups being created, in fact, i punch myself every time i forget to add no-backup as i'm trying to iterate as fast as possible and those backups are totally meaningless in my case. I believe the deployer even created the backup folder for itself, as it's a custom ssp and i'm sure i didn't copy it.

i should clarify - there are backups but not in a separate “backups” folder…right?

Files named like "SuiteCommerce Advanced 2019.1.1-2020-04-22T01-56-13.849Z.zip.001" in SSP Applications -> $PublisherName -> $App -> backups. Of course only for "core", not for extensions (those go to /SuiteScripts/Deploy_extensions)

ok - maybe im thinking 2018.2 or it moved

I have a nagging feeling that backups may have broken in a version and it could have been 18.2.

ha ha yeah - that is correct and sounds familiar.

Part of the reason I think that is because I have backups for a whole bunch of old versions of my test site, except for 18.2

That's what we were thinking. @Kearobi and I are on the same team and I didn't realise who he was. 😄

this is exactly the problem….customers may be held hostage.

I've been in both sides of the story (being the new partner and the old partner) and never had a problem - sometimes it's a repo, others it's a dump. I can understand doing a dump instead of sharing a repo if you want to prevent internal commit history leakage... but with SC/SCA (unlocked, clear) source code is fundamentally needed (even with extensions) so giving sources should be 100% expected. It's sad to read it's not always the case.

I agree….been on both sides as well

In this current economy something could happen to the old partner -- closure or something -- where they perhaps do not take the initiative to hand the source over to the customer. And would the customer know to ask, if they're on 2018.2 and there are no backups in the instance. They would essentially lose the ability to further customize their solution.... or even migrate current customizations up to a newer version.

You can try! Although I am honestly sceptical that the team would make improvements to the 2018.2 developer tools. You would, at least, be registering your complaint. They might be able to provide a workaround

Or if I register a complaint and NetSuite does nothing... then at least I've done my due diligence.