As it stands, an update’s release notes are shown inside ST, but only AFTER accepting and installing the update. At that point, I’ve already seen them because I had to manually go to the ST site using my web browser to decide whether I wanted the update in the first place!
Wouldn't it make sense to show an update's release notes BEFORE making the user decide whether to install it?
That’s a really good idea. I don’t know why i haven’t thought about it. I usually ALWAYS read the changelogs – and (when it comes to apps for example) that’s missing i’d rather wait until there is a changelog. Upgrading just for a typo or so is waste of time.
So yeah, i really second this idea.
This is precisely why no software on my machines and entire network have automatic update enable. Any small minor bug fix can break anything else, and I always test updates and read changelogs before updating. Don’t change something that work …
Automated updates are great. Not just in Sublime Text, but on my phone, workstations, etc. I shouldn’t have to remember to take time out of my day to look for and install updates.
I think there are two problems here that are solvable without turning off autoupdates.
- Updates that break the package and/or require the user to change their config to get it working again (eg a package adds a dependency like Node that must be installed on the system)
- Wasted time reading changelogs that aren’t worth reading (typo fixes, etc)
Item 2 is easy enough—add an option to disable the auto-display of changelogs.
Item 1 can be handled in a few ways. The best approach is for package devs to use proper semantic versioning; a breaking change from 1.1 should result in 2.0, not 1.2. Major releases could then be manual while point releases could remain automatic.
Another way would be for PC to allow for easy version rollbacks of specific packages.
Alternatively, major releases could trigger a confirmation (“Are you sure you want to upgrade? You will need to install Node before the next version will work”) before upgrading.
I think turning off auto-updates will lead to more problems. Most people simply won’t bother to upgrade which means they will have a poorer experience and developers will have more headaches trying to support users running a variety of old versions. I’m guessing that 95% of the time autoupdate works very well for you, but it’s those 5% of upgrades that are handled poorly that makes you want to turn it off. Don’t ruin the 95% to fix the 5%.
I think the problem is… you still won’t know what exactly happen even after you read the changelog. You just have to try it.
Take ST 3103 stable build as an example, Incorporates many community provided improvements to the above packages, with significant improvements to HTML, CSS, JavaScript, Go, D and SQL
is written in the changelog. How do you know this would “break” your javascript syntax highlight before you actually update your ST?
But, yes, it would be good to read the changelog.before an update.
This topic is about ST itself, not packages managed by Package Control.
The problem with Package Control is that it would require an entirely new architecture for update messages, because currently they are contained within the updated package. I highly doubt reworking that to support the features you propose would be feasable or rather worthwhile to spend time on. I mean, it would be possible but not trivial.
I have also been going to the ST site to read the changelog before deciding whether to install an update or not. It would definitely be useful - and in line with almost every other program I use - to have the release notes included with the “update is available, do you want to install?” dialogue box. Or at least a link to them on the ST site!
I do not like automatic updates that cannot be turned off. That would be worse than the current situation, where it is at least possible to make a decision based on reading the changelog on the ST site.
The one time I didn’t read a changelog, the update completely destroyed a feature that I needed to use for almost every part of my job. I was unable to work efficiently for several days until the next update with a patch. I am deeply invested in having changelogs available, preferably easily accessible within ST itself, and no automatic updates.
I am using that, and I’m not getting automatic updates myself. It read to me like some users were asking for updates to always be automatic, and I wanted to make it clear that I didn’t!
I get what you’re saying but… how would you know the feature was broken if you didn’t upgrade and try out the change. I guess the only way to be sure is to not upgrade until the release after when it says “fixed broke feature”.
The “Open Changelog…” button in Update dialog can be used to display changlog before actually downloading and installing them.
Note, it not possible per design to display changelog before an update, if updates are received via apt on linux.
This is an ancient thread. It was bumped probably by an AI spambot that will edit their post soon to link to some junk
Yeah, hence answering in a way they can probably understand and use for training