Sublime Forum

3103 - is it safe to upgrade?

#1

Hi,

I’m really trying to understand if it’s possible for me to upgrade to 3103, but I just can’t figure out if it’s safe or not. Reading in the forum here I get the feeling there are lots of issues and this release is best to ignore. Is that a fair interpretation of the consensus?

Normally I’d just give it a shot and see what happens. I did that once before with ST, and it resulted in a royal mess that took me at least two days to handle and solve. So now I’m really careful when it comes to upgrading ST, unfortunately.

And to give a bit of background for my situation:

  • Debian Stable
  • Only code in php, html and js. I use Laravel so Blade is important
  • I have a theme of my own (copied Sunburst and modified slightly)

So… Is it safe?

All input is very, very appreciated!

Cheers

0 Likes
#2

Just to report back…

As I got no response, and I was curious, I gave in to temptation and gave 3103 a try. Didn’t work, just as I feared. The showstopper was that I couldn’t get Laravel Blade Highlighter to work as expected, which caused lots of problems. I found a handful of suggestions around the net on how to solve it, nothing worked. I removed 3103 and gave 3102 a shot - same problem. Gave up and re-installed 3083. Things work again.

I love ST as much as the next guy, but upgrading is so painful that I would consider moving to a (slightly) less capable editor if they had painless upgrades. :unamused: (That’s not a silly threat or anything like that, just expressing my feelings.)

0 Likes
#3

The thing is … “safe” is already relative. Upgrading was perferctly safe for me and I had absolutely zero problems with it. But I know that everyone puts different expectations on their working environment (the editor), so I can’t judge for everyone.

As an example, I have used the infamous updated JavaScript syntax for weeks before the latest dev build was released and I did not have any problems.

2 Likes
#4

And in this case you should keep the updated version and just override the javascript syntax with either the one from 3083 or the latest one from the github repo.

1 Like
#5

Not sure I understand what the javascript syntax has to do with the problems I had with Laravel Blade Highlighter? Can you explain what I’m missing?

0 Likes
#6

You were also talking about JS in your first post and this is the one most people complain about.
For Laravel it references PHP syntax and I think there was also some issue around PHP, so what I said about JS also apply to PHP.

0 Likes
#7

3103 was a bit rushed release. It seems that many issues have been fixed in dev builds. I hope they will release a new beta once it is properly tested and has no regressions.

0 Likes
#8

Specifically for JS 3103 was a perceived as a bit rough. But you’re relying on third party packages here and wether or not a new ST build is “safe” with regards to compatibility with any random package is not easy to predict. If you really need such a package, you should check the status of that package before making the jump. In this specific case you could have seen that numerous others have already run into the same problems. Checking things like this is something you can do yourself to make stuff less painful.

1 Like
#9

Yeah, you’re right of course. And I did check a bit before taking the plunge, but I didn’t find the results conclusive - which made me give it a shot.

I suppose this whole thing boils down to me wanting a solution with dependencies, like we Linux users get from our package managers. I imagine the backend wouldn’t have to be as complex as it is with, for instance, apt-get. But a simple require-version/recommend-version would probably do wonders.

Meaning, let’s say I try to upgrade ST to 3103 (preferably from within the app itself), and it could simply tell me - before perfoming the upgrade - that I have three packages that won’t be compatible if I do the upgrade, and list them for me. Now, that would be super clear and easy to understand, and I could decide on how I wanted to continue. (Maybe this is something @wbond has on his radar?)

So, anyway, this has turned to bit of a rant, which never was the purpose of my initial question. I think I’ll just risk minimize and wait for the next beta and see what happens then. Until then I would be happy if I could get rid of the update modal that pops up now and then. Gonna give the update_check setting a try, but from what I can read it seems broken. We’ll see.

0 Likes
#10

Packagecontrol provides the means to package devs to limit their package to certain versions of ST that they know are compatible. The problem here is that lots of packages don’t use it, and even if they do they usually expect new versions of ST to be backwards compatible. And that’s not always the case, it being in beta and all that. It’s the same everywhere. The Atom project for instance is pretty good about managing compatibility with their API, and uses the npm/semver scheme to manage package compatibility. But since it runs in a browser, the actual interface to a package is much larger than just the API and this means packages break nonetheless.

So really, ST can’t tell you your packages won’t be compatible unless the packages tell ST they’re not. I believe packagecontrol would already manage this properly and disable the incompatible package, given the proper information. Which is usually missing.

0 Likes
#11

Yeah, I never meant it to be a task for ST devs to handle the dependencies per se, just the system for it. But it’s interesting to read that it sort of already exists, it’s just lacking the info in the package.

I wonder how much this would be improved over time if some sort of linting was done with the metadata and the results was shown on its Package Control page. I imagine many package devs would just take five minutes and fix/add what’s missing. And even better, if the linting show no errors or warnings, they could get a GOLD STAR on the page. :wink: (I suppose I should mention @wbond again.)

Example gold star for inspiration, there are other variants available on the net also. Some are even animated, which would obviously be very amusing and tasteful.

0 Likes
#12

I’m not sure what you mean here by linting with metadata? Are you suggesting trying to scan the files in the package to guess if they are compatible?

0 Likes
#13

No, because that would obviously be crazy. :slightly_smiling:

I was referring to what @braver said above about the fact that package devs have some way of specifying compatibility. Without knowing anything about it, I just assumed that each package have, sort of, a metadata file where there are a number of potential fields to use. The linting - if such a file even exists, I’m just guessing here - would just make sure the metadata file was filled-in and complete. That’s all.

0 Likes
#14

All packages must specify their compatibility to be added to the default channel. So the data/functionality is there, however I don’t know of anyone who adjusts their compatibility based on bugs. Instead it is mostly used to indicate that a plugin doesn’t work with ST2 or ST3, or that a specific build (or newer) of ST3 is required due to new API features.

I don’t know what about Blade broke. From looking at the issue tracker, I see mentions of syntax issues in attributes. The dev builds of Sublime Text are where we expose such changes before going to beta. Perhaps no users of Blade were running dev builds, or maybe they just didn’t notice the changes to the syntaxes?

0 Likes
#15

Also probably no devs of Blade were running dev builds either. I don’t expect many package devs keep up with the bleeding edge to keep their packages up to date. Packages are usually about building something you need yourself and sharing that, rather than being full on committed.

0 Likes