Update Package Control when Mlistone 1 has been merged into master. about ghosttext HOT 21 CLOSED

Also

• Inform the user that we changed name and tell them to install the extension from the Chrome store.

I asked if we can rename ChromeTextArea instead, this way we can keep the existing userbase.

At the very least we should keep ChromeTextArea a little bit longer in there and add an update message. Maybe they already handle the GitHub redirect internally and both ChromeTextArea and GhostText can point to the same repository internally.

from ghosttext.

If it is not possible I would create a simple sublime text plugin in an new repo which only shows an alert to change form "Chrome​Text​Area" to "GhostText". Then I switch the existing package control entry repo to the new "alert displaying" one…

from ghosttext.

Lets wait until we got an answer?

from ghosttext.

Yeah, I'm not in a hurry

from ghosttext.

We got an answer! There's a previous_names key

Before we do this, what do you think about using GhostText-Platform names instead of GhostTextForPlatform? It's a bit easier to follow, it's clearer that the actual name is just GhostText, and it sounds less like the 90's "For Windows". I checked and GitHub will keep track of multiple renames (and will redirect to the final repo)

from ghosttext.

I like the 90's 😄 I had chosen the "for" because it implies that the plugin might exists for other Software, too.

from ghosttext.

What about GhostText-for-Platform at least? This way we get the for, a bit of readability and clear distinction of the name (which isn't "Ghost Text", but specifically GhostText)

from ghosttext.

This is okey, I think I will have enough time on friday or saturday to merge the branch and update package control.

from ghosttext.

I have created a release with the version 1.0.0 because the messages.json seems to need this, now we have to wait until my pull request: wbond/package_control_channel#3417 has been processed.

from ghosttext.

I hope I did everything right 😓 …

from ghosttext.

Install via Package Control worked!

from ghosttext.

Ok, I guess we can start using the branch Master as the development branch since the Package Control version is on its own branch. By the way, why are there two branches for it?

from ghosttext.

The package control is not needed anymore, but I keep and rename it because this http://cacodaemon.de/index.php?id=59 still references code from the old version.

It is no problem because we are using releases/tags now: https://github.com/Cacodaimon/GhostText-for-SublimeText/tags because package control needs tags when using the messages.json.

from ghosttext.

I'm not sure of what you mean. If you just want to keep the old code you can just link your article to the the last pre-GhostText commit in the master, there's no need to keep a whole branch for it.

I'm still not sure why we have two branches named named origin/PackageControl and PackageControl.

Where does Package Control pulls the data from?

from ghosttext.

Package Control pulls the data from the tag, this means package control does updates GT only if a new tag has been created.

You are right I could create a tag from https://github.com/Cacodaimon/GhostText-for-SublimeText/tree/faee6de0a88c07fc4484ad382771b84d3442af22, too.

from ghosttext.

That's great! I didn't know that

from ghosttext.

I din't know about tags, too.

A maintainer from package_control_channel told me to use them:
wbond/package_control_channel#3417

Maybe we should consider creating a tag for each Chrome extension release, too. Then we have a history about the updates?

from ghosttext.

I guess we could, the version will be stored in the manifest.json as well. If you want to add tags no problem, they just won't be much of use though since uploading to the Chrome Web Store must be done manually.

from ghosttext.

Yes the upload is still manually but the history of changes would be nice to have.

from ghosttext.

Basically this? https://github.com/Cacodaimon/GhostText-for-Chrome/commits/master

from ghosttext.

This is just a history about commits but a tag defines a important point in the repo, a release for example.

from ghosttext.