search

acoppes / unity-history-window

A simple selection history window for Unity.
MIT License
293 stars 24 forks source link

Update upm version or change master branch to packet-style #26

Closed Team-on closed 3 years ago

Team-on commented 3 years ago

Since Unity 2019.4 package manager can install plugins directly from git, so it's preffered way to install plugins. Please, upgrade #upm branch. Or even change master branch to upm, so you didn't need to run custom scripts to create release

acoppes commented 3 years ago

Hi, there are already some branches/tags to use for that but with specific version. You can also use OpenUPM to install the package if you want. I will delete the branch upm to avoid misunderstandings (it was a stale branch, two years old, sorry for that). Thank you for your report.

Team-on commented 3 years ago

What about changing repository to unity package format? So it can be intalled & updated via package manager. Like this repository do https://github.com/smkplus/CustomToolbar Here are a docs about that https://docs.unity3d.com/Manual/CustomPackages.html

acoppes commented 3 years ago

Hi, it can be installed with unity without problems, just point to specific version, for example, go to add package using git url and add https://github.com/acoppes/unity-history-window.git#1.0.4 and it will work, or if you use OpenUPM just add it with their add package command or by adding it to scoped registries manually.

I prefer not changing the main branch of the project to match the upm format because it is the development branch, it has more stuff (a unity project, test scenes, etc) not just what you download through unity package manager. So for example, if someone wants to collaborate with the project, they will normally fork and fetch main branch and then work from there, and imho, it is more intuitive and suitable for development. If it wasn't unity, or if upm worked in another way, I don't want to change my main branch of the project to match that and I can always have customized branch.

Also, I prefer to make stable releases and have main/master branch with work in progress stuff, once I think it is usable, I create a new stable release using branches and tags.

Hope this explains how I prefer to work and manage the plugin.

Team-on commented 3 years ago

Thanks you for explaining me!