i'm writing a snap mod and i want to keep full project compatibility. problem is, snap extensions and javascript can access pretty much anything within the snap code. it would absolutely be possible to just take all the snap files, get their hash, and make a project that just shows the hash, which would have behaviour that changes every update.
which features are supposed to be kept each update? are there any apis that will always work the same for extensions and javascript?
i'm also just not sure what the actual versioning scheme here. it LOOKS like semver, but i'm not sure what exactly a major version would break the compatibility of. have any updates broken old projects? are project files made in a newer patch version supposed to be able to load in an older patch version?
Major releases change and add tons of stuff, whereas minor releases may add or change smaller things (I'm pretty sure some blocks have been added in minor releases). Patch releases usually tend to just be bug fixes, translation fixes, etc.
There is an extension api in api.js, which will probably stay the same, but anything else might change for new features. However, you probably don't have to worry about compatibility, because functions usually don't get renamed, changed return values, or changed parameters. Instead, new methods are created (while probably modifying older methods to use the new methods, and also add some new properties on objects).
We're not as disciplined about version numbering as you'd like us to be. Sprite prototyping OOP was added to BYOB in a minor version number. (3.6? Am I remembering that correctly?) That deserved to be 4.0, except that Jens had already planned to release Snap! as 4.0, changing the name along with the major version number.
We try pretty hard not to break old projects in new releases, to the extent of detecting what version created the project and translating the user's code to newer blocks if necessary. But there is absolutely no promise about new projects running in old versions! That hardly ever works. When we release a new version, we're done with the older version. :~)
On rare occasions we decide we got some new feature wrong, and make an incompatible change to fix it. This happened with the meaning of a list as the first input to ITEM, for example; we changed the order in which items of that list correspond to dimensions in the second (data) list input, and that change is documented in the manual.
We're much more likely, I'm afraid, to drive users crazy by changing something in the GUI, such as the appearance of blocks. Sometimes it's for a good reason. Zebra coloring was controversial at first, iirc, for example.
Although there will always be people who enjoy modding Snap!, our strategy going forward is to try to make the extension mechanism take care of people's serious needs for modified versions, so that those "mods" (extensions) can automatically keep up with new releases. This is good for us as well as for the extenders, so we can benefit from each others' work.
i'm not making a snap extension. i'm making a fork. i want to know how much i can change so that existing extensions, projects, and whatever else remain compatible.
the problem with making everything behaving exactly the same is that if i do that, i can only change things within individual functions to make things faster. snap has pretty much no encapsulation.
my plan is to convert everything to js modules, make encapsulated classes with private properties, then i can start doing larger optimizations and restructuring.
i want to keep full compatibility between snap and my fork. projects and extensions should work the same in both (as long as the fork is kept up to date with snap)
Well, the best advice I can offer is that Jens publishes very detailed release notes, about every little bug fix and translation tweak. So even though you can't deduce a priori how a new release might break something, you can keep up if you want to put in the effort.
my issue isn't that snap gets updated and i'm not sure how to keep up, my issue is i don't know what things a snap extension or snap project has access to with js that they aren't supposed to use.
some examples:
i could speed up sprite blitOn for svg costumes by making svg costumes keep the rasterized version, but that will break any extension that directly edits the costume shapes. i can only make the change if extensions explicitly aren't supposed to do that.
are extensions supposed to be able to read and write Morph lastTime? technically StageMorph does it, since it overrides the step function, but it would be a lot nicer (and probably faster, i haven't benchmarked) if i could replace the Date.now() calls with performance.now() calls.
the Node functions are clearly not designed to handle cyclical nodes or nodes with two parents, but nothing actually prevents it. a library could use the same morph in two places, and this probably has happened by accident.
when you exit the block editor, the BlockEditorMorph calls Process reify with .call(null, ...), and because it tries to access this.context and snap scripts aren't in strict mode, they access window.context instead. an extension could just put any object in a global variable called "context" and it would completely change the behaviour without even touching anything related to Process. i'm pretty sure this one is a bug.
nearly every constructor prototype in snap is an instance of the class it extends, which means if an extension were to get the prototype of any of these classes they could modify the fields and use it like any other instance.
there's some things in snap that aren't expected to change between versions, because extensions rely on them, but there's also some things that are expected to not be used or be changeable at any time, because snap gets updates that clearly do change the behavior.
i can't tell what in snap is an api, private, feature, or bug.
TLDR; Please move on, this is not the place to discuss the Snap source.
Pretty much everything you wrote on your previous post raises red flags for me, because these are precisely the kinds of remarks I do not accept here. This forum is meant to support teachers and students who use Snap! in the classroom to study CS and for leisure. This is not the place to discuss how Snap! is made using JavaScript. AFAIK there is no such place, because I am not interested in discussing Snap! architecture and implementation with the unwashed masses. My every edit to the Snap source is always (brutally) public in real time, for everyone and anyone to track. And that's precisely how far I'm ready to take it, not any farther.
If you want to make the world's greatest / fastest / easiest / most powerful / whatever programming language, please go ahead and do it! If you (srly?) believe that starting with my code helps you, be my guest and knock yourself out! But please, oh please, spare me the details of your genius here. This place exists to engage and empower learners and folks willing to share and help with that. This is not, never, ever a place for nerds to indulge in Stack-Overflow tech chats.
Therefore, let me spell it out once more: Do what you want but don't talk about it here, and don't try to get into a discussion with me.
Snap's versioning focuses on the user: Patches require no documentation update, minor releases introduce a new feature or a notable change in behavior requiring documentation to be amended, major updates feature new experiences such as a paradigm shift or a new mode of interaction. Major updates require the manual to be rewritten or restructured in essential parts.