Migrating Deprecated Attributes

In the latest update to the sheet I'm helping to maintain, I've refactored how we handle the sheet styling, and in doing so have eliminated the need for a few attributes.  The chances of these being used in a player macro are quite low, as they're simply "off" or "on" (and only one "on", at that!)  but I've taken steps to migrate what use they had to the new attribute via a sheet worker that runs on sheet open (and doesn't call the costly setAttrs if there's nothing to change) . What I want to know before I publish this change is twofold: How long is it prudent to maintain this migratory sheet worker in place? Are there any missed steps that I should take when removing attributes? Thanks for your time!

The sheep migration code should remain indefinitely on the sheet, no real reason to remove it. Just make it so it runs/check only once, so that it's never triggered again after teh migration have been done, but the code exists so that if someone picks up their old campaign 2 years after the migration was done, the sheets will be updated once they have been opened at least once Speaking of, the Sheetworker pages on the Community Wiki could really do with a simple and clean example of how to migrate an attribute, if someone smarter than me is inclined to create one...

I've put checks into the sheet workers to prevent them from doing the bulk of their processing in the event that things are "as-expected" for this version. Would probably be easier to just add a hidden attribute to hold a version number, and then run the migrations if the version is below their introduced point? ᐰndreas J.  said: but the code exists so that if someone picks up their old campaign 2 years after the migration was done, the sheets will be updated once they have been opened at least on Hadn't considered that possibility. I'll leave them in, then!

Would probably be easier to just add a hidden attribute to hold a version number, and then run the migrations if the version is below their introduced point? Yeah, that's how I've understood the more robust sheets have done it. The main 5e is pretty massive, but there should be other sheet examples on how versioning is handled. This section have some links to a versioning script by GiGs, that might be helpful: <a href="https://wiki.roll20.net/Sheet_Author_Tips#Sheet_Versioning" rel="nofollow">https://wiki.roll20.net/Sheet_Author_Tips#Sheet_Versioning</a>

I'm a big fan of the way Aaron handles versioning with a switch block, allowing fall-through for different versions. It's probably overkill for this purpose, and I haven't played in the Sheet Sandbox, but I don't see any reason why a switch block wouldn't work in a sheetworker. It's a kind of "fire and forget" approach - you just add to the end of the block each time you update, and if anyone is 5 versions behind they get the same updates as anyone else by falling through the version numbers. Very clever! It would need some tweaking to be sheet-specific, as the linked code is for an API script.

I added a link to Aaron's versioning to the wiki page.

The wikiGod strikes again!