Sublime Forum

Adjust versioning strings for a release vs. development plugin?

#1

Greetings,

I’ve been quite enjoying using ST3 + Deviot for Arduino programming, and wanted to contribute where helpful to the development. I’m newer to python, so my contributions will be pretty simple. One of the issues on github relates to installing the developer version, and I noted that there’s not a great indicator of which is installed in ST3.

I read a little about Package Control and see that x.y.z versions are encouraged via the use of git tags. That’s what @gepd is doing for the published package, but I wondered if there is a way to trigger a different version for the manually installed develop branch using Package Control -> Add repository?

Here is what one sees at present: the release + the added repo listing:

The date code is a giveaway that it’s a rolling release, but both show their origin as the same (github).

During install we have clues, but once it’s isntalled, it’s not clear how to get at the version. Both output [Deviot 2.1.1] in the console. So, say I submit an issue and @gepd says it’s fixed… how can I be sure the change propagated?

I found quite a few posts on tags, but they seem to center around releases… is there a way to do something different for users who manually add a github repo through Package Control?

  • perhaps show the git rev-parse --short HEAD version
  • prefix/suffix a release with dev
  • auto-increment some “fake” release version (e.g. maybe dev is always 0.0.xxx?)

I’m wondering if others deal with this and have suggestions. Thanks!

0 Likes

#2

The main issue here, I believe, is that you are using different folder names for the development and releases packages. Adding a package via repo URL just uses the repo slug as the package name, but the author is publishing the package under a different name on Package Control.

The v2017... is a faked version number, based on the date of the last commit.

If you want to use git to develop a package, I would git clone the branch used for development into a folder with the package name inside of the Packages/ folder. Then package control won’t try to install or update the official releases, and the listing will show it as a git repo instead of showing a URL as the source.

0 Likes

#3

Another problem here is that I missed the fact that the renaming PR wasn’t proper and was missing a previous_names entry.

I’m note entirely sure why the website still lists “Deviot” (and consequently the install package quick panel within ST) since it should be missing, but I will fix the original issue later.

The proper way to distribute or use development packages would be to have the author tag a pre-release. The more “rolling release” but manual way is to just git clone the repo, although you can configure Package Control to update these as well. (It just never worked for me.)

Other than that, as @wbond said, you need to remove or disable the original package initially installed with package control if you manually add a repository with a different name, since they will not override.

0 Likes

#4

Thanks @wbond. In this case, I’m focused on the consumers of the package who would want to track with the develop branch. In that case, they would want the package to update with any new changes to that branch. I might be messed up on terminology, but when you say:

Then package control won’t try to install or update the official releases

Does that mean it wouldn’t try to install/update tagged releases (as in, the release that’s hosted in d.json in package_control_channel, or install/update based on the actual branch? I would want the latter, but am fine if it ignores the official Package Control package. I assumed that new commits would push an update to ST3, but maybe your’e saying that’s not the case.

If you prefer the “version” to be the faked date of the last commit, that’s cool. I think it would be nice to standardize to a git commit hash.

I see another comment came in… is the consensus that users who want to track a development version should just git clone into the Packages folder? If that’s the case, what is the intended purpose of manually adding a branch URL into Package Control? Primarily to try a package that isn’t currently in the PC listing?

To clarify: only one package is installed, the tree/develop one, not the one that comes from the package_control_channel. I’m looking for the recommended way to version that; it looks like it tracks the tags of the github repo, just like the “regular” package does (both say v2.1.1).

Edit: I did find that Package Control -> List packages handily shows the fake version date string, so that’s handy and would serve to verify the version string. I think that’s answered for me now!

0 Likes

#5

If this is the case, you should create a semver tag with a prerelease suffix. E.g. 2.0.0-beta.1. Note the - followed by dot-separated labels. Each user who wants to install prereleases of your package will need to add the package name to the install_prereleases setting. After that, Package Control will install the newest release, even if it is a prerelease. You can create prereleases via tags from your develop branch whenever you see fit.

If you wanted to get into having every release from a branch created as a release, you’d have to get into hosting your own repository JSON, but the version number comparison won’t work with the regular releases. Explicit versions are always considered greater than date-based releases.

0 Likes

#6

These are the current instructions:

  1. To upgrade the files open the Package Control quick panel Preferences > Package Control and select Upgrade Package. After some seconds the plugin will be updated.
  1. If there is a new change in the branch and you are not receiving the update, select Upgrade/Override All Packages From the Package Control quick panel.
  1. Restart Sublime Text each time a change is pushed
  • is this accurate? As in, adding a repo pointing to repo/tree/branch will update with each commit? Your note about adding the prerelease and that “After that, Package Control will install the newest release” makes me think a tag is still somehow required to trigger an update?
  • if it does auto-update based on a new commit, then updating (in my mind) already has the desired behavior without adding an immense amount of tags
  • in that case, it’s more about finding which version one is on and since posting this I confirmed the commit date string, so perhaps that’s the way to roll. Seems pretty easy and could just be added to the wiki instructions for users wanting to check.

I am now wondering if master is the source of tagged releases; if so, perhaps the develop branch could maintain a different version string based on the commit hash or date. This would make the version more obvious in the console output.

0 Likes

Mods: please assist with hidden posts
#7

No, this looks incorrect since it isn’t specifying the custom package name, but just using the repo slug.

This won’t ever work in tandem with official releases, unless you use a separate package name. This is because all date-based releases are evaluated (when comparing versions) as 0.0.1+2017.… (https://github.com/wbond/package_control/blob/master/package_control/versions.py#L32-L43).

Commit-based releases are deprecated and generally pose a lot of problems. They still exist for situations where a package developer doesn’t want to, or isn’t yet part of the default channel, but you won’t get them to play nicely with explicit versions.

You can’t have your cake and eat it too, unfortunately. If you want it seamless for the end-user, the developer will need to create tags when work is “ready” to be tested. If you want it super-easy for the developer to not create new releases, then you’ll have to support multiple package names in the codebase and supporting files. If anything in the package references a package name, it may be incorrect if you have multiple different names the package is installed under.

If this is really for development work, the end user should clone a git repo into the Packages folder. If they aren’t able to do that, they probably won’t be able to deal with the bugs resulting from running untested, in-development code. (That’s my general opinion on the matter.)

As outlined above, it gets complicated quickly if you are having different package names and mix commit-based and explicit versions. I think the prerelease functionality is what I would encourage. If you find some other way to do what you want, that is fine, but I probably won’t have time to try and make such things clearer/easier since they are necessarily complex and not the solution I designed to solve the problem.

In git tags are not tied to a branch, but instead are conceptually separate. Tags can be created on any branch, and aren’t tied in any way to a branch.

This is the sort of thing I want to avoid by deprecating commit-based releases in the default channel. It makes it super easy for users to upgrade to half-finished code, makes it impossible to do meaningful release notes, makes it impossible to use prereleases functionality, etc. If you want to write some sort of script that automatically creates tags in some branch for the sake of your packages users, that is fine, but I don’t think that is something I’d like to add to Package Control or the default channel server.

There is already plenty of complexity in Package Control in regards to repositories and versioning, and I don’t think adding another layer is going to help. I think having users clone via git, or using developer-created prerelease tags should be good enough for 99% of situations.

1 Like

#8

No, this looks incorrect since it isn’t specifying the custom package name, but just using the repo slug.

I’ll verify next time a commit is issued and see if it updates from the current date string.

Commit-based releases are deprecated and generally pose a lot of problems.

Hadn’t thought about that, and your other comment about the issues they pose makes a lot of sense in hindsight!

If you want it super-easy for the developer to not create new releases, then you’ll have to support multiple package names in the codebase and supporting files. If anything in the package references a package name, it may be incorrect if you have multiple different names the package is installed under.

I don’t follow this.

  • Package Control default points to the top level repo: https://github.com/gepd/Deviot [1]
  • I’ve added this repo: https://github.com/gepd/Deviot/tree/develop

I’ve only installed the latter; the version shipped with PC is left uninstalled. Where does the collision risk arise from?

Also, how are updates decided for the url/tree/branch format? It seems like they aren’t at all per your first comment above. That will definitely be good to know and update on the instructions.

I think having users clone via git, or using developer-created prerelease tags should be good enough for 99% of situations.

That is definitely the direction I’m leaning after hearing your thoughts (much appreciated, btw!). I think it sounds simpler to just clone and update manually, in particular because one gets the full .git history attached. Downloading the .zip files doesn’t provide this ability.

Thanks so much for the time in explaining things. I absolutely was not expecting this to change Package Control in any way. I intended to just do some research for the purpose of helping out with a small change for users of the development version of this plugin. Seems like this is a lot more complicated than I expected!

[1] Weird. In posting I was told I “cannot post a link to that host” when trying to show the line in d.json. Here it is if you want to look: https://github.com/wbond/package_control_channel/blob/master/repository/d.json#L493

0 Likes

#9

I confirmed there’s no auto-update upon starting ST3 for an update. Not sure if that happens with Package Control on an “official” package tracking the top level repo. A commit does trigger an update if I manually do Package Control -> Upgrade packages, so it’s definitely watching commits. I posted an issue on github so the author can consider the great input here with the versioning strategy.

Thanks for all of the explanations and information you’ve provided!

0 Likes