ziming/json-field-for-backpack

Backpack v5 compability

Closed this issue · 7 comments

howest-ward commented

Is it possible to make this awesome field compatible with v5 of backpack?

ziming commented

Your wish has been granted.

  • 😄1
howest-ward commented

Sweet! Thank you!

tabacitu commented

@ziming , heads-up, I think the >=4.1.0 requirement is bound to create problems one day. As I understand it, this covers v5, v6, v7, v999. But we cannot assume this version of the blade file will work for ALL backpack versions from now to infinity. Most likely there will be some breaking changes one day.

I think ^4.1.0|^5.0 is a much better option - we know for sure that it works under these two versions. When v6 comes out, we can just add that too, if it still works.

While this doesn't pose an immediate problem, I'm pretty sure it will in a year. I recommend nipping this in the bud, by

  • deleting the 1.1.1 tag,
  • changing composer.json as above,
  • releasing 1.1.2 instead.

Just my 2 cents. But you know... you do you 😅

ziming commented

Very silly post from me. I haven't really sleep again today

Hmm I have a few reasons for choosing >= when I 1st made that commit. One of which is that this is not a customer facing package but an internal staff facing 1 where having it break is more tolerable. So by doing >=, at least people don't have to wait for me when future major versions of backpack is out to upgrade (Tho they can still learn how to use a fork or composer patches. I do know how but even then I find myself being lazy & end up waiting for the maintainers to merge my PRs which sometimes take months/forever until I gave up & link to my fork/composer patch instead).

& if it breaks, they can then comment out my admin field & post an issue here on what they are facing in the new major version. At this time in my life I'm also not sure how many more years do I want to continue as a developer too. So >= in a way may allow this package to work longer

Another silly reason tho, is I originally only plan to release updates to this package once every year on the same day for personal reasons. So I was hoping >= will reduce the times I need to patch it & make a new release

Hope you give me some time to think about it. If I do release a 1.1.2 in the coming days, I may not delete 1.1.1 though. I once remember a maintainer did something similar & people are not happy about it on twitter as it broke their deployments (I guess the timing of their deployment is when their composer.lock is at "1.1.1" but the maintainer deletes it at that very moment when their deploy script runs composer install). But my packages aren't popular enough to cause that kind of issue to people heh.

tabacitu commented

Sure - I understand your position / pondering. Take your time. But also take into consideration that:

  • Composer itself heavily recommends having an upper bounds constraint;
  • the longer you wait, the more potentially "damaging" it will be to delete the 1.1.1 tag, because it'll have more downloads;
  • if you don't delete the 1.1.1 tag, you don't really solve anything; even when this package gets to version 9.9.9, you'll still have version 1.1.1 in your history, that can be installed on "any" backpack version, ever; that's the problem I was highlighting;
  • I've deleted tags before, when I made mistakes, in packages that had a lot more downloads; it's not that big of a deal 😅 some people get a bad experience... so that MOST PEOPLE do not; the trick is to do it fast 😀

For context, I'm not a "strict" developer, by any means. For example, I like form validations more lax, rather than more strict. I rarely use return types. My methods default to "public". But when it comes to package versions - my opinion is firm, based on experience... "stricter is better". "Packages should only be installable on configurations you know will work."

This is why working with Composer & Packagist is great, and working with NPM can be awful sometimes - people in the JS ecosystem allow their packages to be installed on whatever and let the dev "see what happens". It amounts to an awful developer experience, if you ask me. Much worse than trying to install, telling you it doesn't work, then having to submit a PR to have it work (or making a fork). And by consequence... helping the maintainer maintain the project.

My 2 cents, of course 😀

ziming commented

Done. Hopefully I deleted it correctly.

tabacitu commented

Yup - just checked, 1.1.1 is no longer on https://packagist.org/packages/ziming/json-field-for-backpack so it's all good now. Thank you @ziming and sorry for all the back-and-forth.