Closed Forceu closed 3 years ago
Thanks for opening your first issue here! Be sure to follow the issue template!
This will be done once alpine 3.13 is released and we've done our usual test/migration process with it.
The build of tag/release 3.0.1 seems to fail because of the php-version now so the actual release of the container isn't compatible with @Forceu's latest version of barcodebuddy. If I understand this correct Alpine 3.13 has (had) a milestonedate of 1/1/21 but is not close to be released. So question is, is there anything that can make this container possible with grocy >= 3.0.1 now?
@nibblerrick in the meantime you can still use the image with the tag v1.6.5.0 to use a version compatible with Grocy 3.0.0
As far as I am aware @berrnd made the decision to move to 7.4 because it is only tested with that. A dirty fix for this problem would be to modify the version requirement during the build, I will create a PR for that. I am running the new version with 7.3 without any problems and I don't think that there is an actual requirement for 7.4
Yes, it was just about that I cannot test old(er) runtime stuff all the time, it was more about problems when using really old SQLite versions, but PHP older than 7.2 definitely doesn't work.
https://github.com/grocy/grocy#how-to-install
- Based on user reports, the minmimum required/working runtime is PHP 7.2 with SQLite 3.9.0
- However, I don't really care about supporting old runtime stuff, currently everything is only tested against (means 100 % works with) PHP 7.4 with SQLite 3.27.2
PHP 7.4 was released over a year ago, the mentioned SQLite version is nearly two years old - so I think this is fine (I'm not requiring bleeding edge versions) and really don't see why this should be a problem...
the minmimum required/working runtime is PHP 7.2 with SQLite 3.9.0
With the change in the composer.json file Grocy 3.0.1 does not run on any version older than 7.4. Should I open an issue for that on the Grocy page?
No, I will not change that, as it would mean I have to test every change again with PHP 7.2 to fulfill that.
If someone wants to run it with PHP 7.2 and it works, why not, however, it can break with any future commit.
I still don't get why it's so hard to use PHP 7.4 (newer is most of the time better/faster/less resources/...). (If it's hard here, maybe that's why I personally never started using Docker for anything I run myself...)
It is not hard, 7.4 is considered unstable for the the version of the OS we use in the container(which is the latest version as the time if writing)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Next push runs php 7.4
Grocy changed their composer PHP requirement to 7.4, starting with the next release (https://github.com/grocy/grocy/commit/f1efd08bc692968856c0446f27cc9284c0200579). Right now the PHP version for this docker image is 7.3. 7.4 is technically not required, the author did this, as he is testing with 7.4, but it might change in the future.
These are the options: