Sublime Forum

Side-effects of bumping version requirement for package in Package Control?

#1

I’m wondering what the side-effects of bumping the Sublime Text version requirement for a package in Package Control is.

I want to take advantage of new features in newer builds, but I don’t want to maintain the package for multiple versions.

I know that the package won’t be installable for anybody using a version of Sublime Text less than required. But what about users who already have the package installed. Package Control won’t auto uninstall the package for those users will it? Or complain about the installed package?

Are there any other side-effects I should be aware of?

0 Likes
#2

PC won’t uninstall or complain about packages which cannot be found anymore. This applies to packages that went missing and to packages that don’t provide a matching release anymore. Just make sure that the channel is updated before you push the incompatible release.

You may provide a separate channel with the previous version using a different tag prefix, but I suspect you know about this already and just don’t care about ST2 users. (only recently someone removed ST2 support by using the new scheme format and has two issues created from people still on ST2.)

0 Likes
#3

Thanks. I’m aware of the tag prefixes and will probably use them when upgrading my st2 compatible packages. Most of my packages have always required st3. As far as I know there’s no way to use tag prefixes to distinguish between two different st3 versions. I’m not sure it’s even worth the hassle though.

I’m mainly concerned about how existing users are affected by version bumps. I’m fine with telling users that for new features and fixes they need to upgrade to the latest ST version. I’m conscious of the difference between the dev builds and the general releases too. There has really only been one general release: 3143. I’m going to try to keep my version bumps to the general release versions, because it’s not fair to be asking users to upgrade to dev builds.

So right now I want to start bumping my packages that already require st3 up to require a minimum of 3143. I think that’s pretty fair. This should really be the minimum version that st3 users should be using.

With each new general release I’ll be looking to bump some packages when I want to take advantage of the new features without the maintenance overhead of keeping it backwards compatible. The new color scheme format is a good example. It’s just not worth maintaining two formats. So on the next general release I’ll be looking to bump the version requirement, convert to the new format, and remove the old one, and be done with it. At this point, I think 3143 is good minimum requirement for most st3 only packages.

0 Likes
#4

You can do the same as you do to separate ST2 builds an indefinite number of times. You could in theory provide a “release channel” for each individual build, provided you build selector string is restrictive enough.

That said, you probably don’t want too many compatibility releases because things tend to get messy after a while. To err on the safe side, you could just bump the minimum version of the st3 release but not update the maximum version of the ST2 channel so that users aren’t downgraded (would only happen if the ST2 release has a higher version number). Imo it is sensible to require a certain stable build after a while, though I usually anchor my packages to the build that a certain feature has been added, even if it’s a dev build.

Also note that old color schemes will still be supported by st in the future and most likely still be used by old packages or things like color sublime.

1 Like