In order to move my course materials from Scratch to Snap I need a stable version of Snap (this is the need that makes me use still Scratch 1.4 instead of Scratch 2 or 3). My students indeed create large multimedia Scratch projects (100-300MB) with many images and sounds and they cannot risk that their project become unusable for any reason (they are not computer science majors and I would risk a stack of dead student bodies at my door).
I can start creating a fork of Snap (with just the current features) so to add with each new version just the bug fixes. In order to do this, I will need to know for each modification of a new Snap version if this modification is a bug fix or an improvement or a new feature.
Is this kind of info something that could be added in the code or in the new release notes? I know that short info about bug fixes and new features are in the new release notes, but at the moment they are too short in order to be sure that I'm not adding something that could possibly break what was previously working fine.
I can confirm that relying on browsers can cause a lot of troubles (we had a tool that created learning objects in the SCORM standard that we had to abandon as it kept crashing almost every update of Chrome/Firefox). That is why I usually freeze the PC of my labs, so that their browser is never updated.
I'm aware of this. Having a clear indication of which part of the code solves a given bug (even a bug caused by the solution of a previous bug) would help me to maintain my stable Snap version.
Jens, as you have seen, are adding notes about bug fixes and new features for every release. No only release notes, you can see more details on HISTORY file.
More details than this, see github commits, with every diff showing all changes.
But, is this worth it? We very much care about old projects working fine! Backward compatibility is important for us.
If you want, you can use a frozen version of Snap! and, when you update, look at the changes and test what you want, and only if you think it's necessary at that time, you will do the fork and so on.
A last comment. I use Snap4Arduino. It's a desktop Snap! version with some addons (arduino features and a webserver). But it's a full Snap! distro. There you have a frozen Snap! version and also a frozen browser version. Maybe it is interesting for you.
Jens, as you have seen, are adding notes about bug fixes and new features for every release. No only release notes, you can see more details on HISTORY file.
More details than this, see github commits, with every diff showing all changes.
Yes. And they are all very useful. What I was asking is, if Jens thinks it is a viable strategy, adding some more details. For example, looking at the diff I can see where the changes are, but I'm not always sure if I'm correcting a bug or I'm adding unnecessary new code that could potentially break Snap. I mean, unnecessary for me as the current Snap version is well beyond my students' needs.
But, is this worth it? We very much care about old projects working fine! Backward compatibility is important for us.
This is exactly my point. What I want is to get is a bug-free Snap, even without new features, that is able to run old projects. So I just need to remove old bugs.
If you want, you can use a frozen version of Snap! and, when you update, look at the changes and test what you want, and only if you think it's necessary at that time, you will do the fork and so on.
This is what I want to do, avoiding, as much as possible, the need to extensively retest the updated version when I add the new bug-removal code.
A last comment. I use Snap4Arduino. It's a desktop Snap! version with some addons (arduino features and a webserver). But it's a full Snap! distro. There you have a frozen Snap! version and also a frozen browser version. Maybe it is interesting for you.
I'd like a lot the idea of having a very small package, but the need of having a stable release is much more pressing. Do you have suggestions about good practises to package a frozen browser in my installation? Thanks in advance for any suggestion.
You can use nw.js to make an app from a web project, and that app will have a Chromium inside, a "frozen" chromium version.
I pointed to Snap4Arduino with the idea of optimizing efforts. It has no sense everybody building his own Snap! desktop edition. Hours dedicated to know about nw.js, builders, chrome versions... can be beneficial for everybody.
And about more details in Snap! changes... I think it is not possible. You are asking for infinite documentation! When a bug is fixed, is fixed using a current state. To know if this change is directly applicable to a frozen version implies having a complete knowledge of Snap! code, and also, hours to investigate if these are affected by previous changes. And yes, I've said "infinite" because there are a bunch of previous states!
You can use nw.js to make an app from a web project, and that app will have a Chromium inside, a "frozen" chromium version.
Thanks a lot Joan. I will certainly have a look at it.
When a bug is fixed, is fixed using a current state.
I understand that. But even having a suggestion if a change in the code is something related to a new feature of it is a bug fix of the previous version would help me a lot in maintaining my frozen version as bug-free as possible.
This is neither here nor there with respect to your request (about which I do agree with Joan that you're underestimating how much extra work you're asking Jens to take on in the press of a new release), but in the clause I quoted, I think you have a wrong view of how we develop new features. Some new features (the ones I design, I'm afraid) are addressed to advanced programmers, but others are to simplify programming so that beginners can accomplish commonly-desired tasks. An example is the 5.0 feature that allows you to drag a CSV file onto the Snap! window and have it automatically appear as a variable whose value is a list of lists. Before that feature, you had to understand the distinction between a SPLIT and a MAP of SPLIT. Now it just happens.
Actually I do have such a feature of my own, namely, the crayon library, whose goal is to let users get a wide range of useful colors without having to understand HSV vs. HSL and all that.
I'm not saying that Snap has useless new features. Not at all. Without those features -as I clarified in Heidelberg- I would never had the possibility of developing the BloP extension. It would have simply required too much time to just a single person to be developed.
But, as my students do not need new features with respect to the current Snap state, avoiding to add new features to the Snap version they use I can avoid adding new issues to my frozen version, issues that, more easily, are linked to the addition of new features.
I don't think so. Otherwise I wouldn't have asked it. But I can be wrong. I have seen a lot of places in the Snap code where I see comments saying "this fixes this bug". Usually solving a bug takes just a few lines of code. Not always. If it takes just a few lines the usual comment "this fixes this bug" could be added to the code. If not, a comment in the HYSTORY.md saying that the solution to the bug is spread in several places would be fine too. Anything would help.
But I can be wrong. If Jens thinks this cannot be done, I can accept this answer to my request
