Upgrade the app to Feathers-Buzzard and the newest Vue/Quasar
Closed this issue · 7 comments
This should be easy, did it a few days ago for my project, I can give it a shot if you want ...
Just one issue which I haven't quite figured out though: feathersjs/feathers#758 (comment)
This is not an issue in a standard Quasar app generated with the Quasar CLI but it's somehow related to the Feathers client.
Hi, yes it would be great to have a PR on this, I can add you as manager of the repo if you'd like to help maintaining it.
For now I created tags for old versions like https://github.com/claustres/quasar-feathers-tutorial/releases/tag/0.13.4_2.1.1 but may be it is better to create branches ?
I'm largely done with the migration, did a little write-up of my experiences in a blog article: https://medium.com/@leob6/feathers-buzzard-a-short-migration-guide-61182cf8361e
Tags sound good, branches might be a bit overkill ... if you want you can make me a manager, a PR is also fine, just a question however:
Am I right that the code of the client part is also available somewhere in another repo as a "quasar template"? Somehow I think I remember having seen that, maybe that should be upgraded too then.
Sent invitation to make you collaborator on the repo. Yes there is another repo similar to this one, which holds the "official" Quasar wrapper for Feathers (i.e. backend for chat app on dev branch): https://github.com/quasarframework/quasar-wrapper-feathersjs-api. The readme contains the link to the Quasar frontend template associated with it (feathers-api branch). If you'd like to upgrade the backend you'll need to create PRs since I am not the master. If you'd like to upgrade the client I can also make you manager of the repo, let me know.
Thanks for your help.
You can a link to your medium article about the migration in the README, would be great.
That's a good idea, I've added a link to the article to the README.
I've finished the migration of the server and the client (while doing that I've used my article as a guideline, that was pretty helpful). All done, updated the README, pushed the changes and added a tag (the tagging is pretty useful).
Closing the issue now.
By the way I just tagged the code just before your update https://github.com/claustres/quasar-feathers-tutorial/releases/tag/0.14.1_2.1.4. Indeed I used to let the last version be the master branch and only provide tags for older releases so that we can fix issues on the master branch without the need to regenerate a new tag for each fix. But we could also create a tag for the latest available master and manage this like a "semver software", let me know what you think.
Yes I suppose you're right, the master/head is automatically the newest (current) release, so there is no need for a tag, even more so because changes/fixes we make afterwards would require "moving" the tag, that's obviously not very convenient.
So I agree, no tag needed for the "current" release until we want to make a new release.