New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
process of new version developing #1021
Comments
No commits have been made since July 20th 2018. So I think we are not discussing ETA to next release but ETA to a new main developer. Until we have one, we will not have any releases for sure. However I would be curious, what the current state is. |
The latest project info is here: https://www.patreon.com/posts/its-end-for-me-22527966 So @christianlupus is right, it's actually ETA until new maintainer. |
. |
Having 5 devs is probably more than useless without solid project management (and probably funding at this stage), the project can survive with one or two, and the only resulting issue may be the development time. One issue she pointed is pretty clear : issue management, and handling people with bad behavior. The project can happily live with two devs, even with health issue, as long as there is people to do issue triage and community management so the developers can focus on a task without having to worry about the other things. |
. |
PartKeepr would have used yet-another-framework the same argument would apply, Symphony isn't really some niche-framework. Yes it needs someone who knows or is willing to learn it, like any other framework. And yes it might be a niche application, but the context is to take into account, if you knew symphony, would you be motivated to join a looking-dead project ? probably not. |
. |
It is not more advanced than another, it is just a framework, yes you can use a very light one, but at the end of the day you will have added a tons of extensions or made them from scratch for the same result, and even worse since it won't be as documented and tested as the "advanced off the shelf framework".
We are not talking about Win32 apps here, and unless you have a POC to prove that it's not doable with the current framework, then it's BS. If you says that "symphony learning curve is too steep" how a custom-made-thingy is supposed to be better ? Now ranting that "symphony is bad and the project is doomed unless we rewrite everything" isn't gonna make the project move further, working on the PRs and with the contributors is. |
. |
No. No framework will do that. I think you have a misunderstanding of what a framework is. The implementation of Categories is something application-specific, and no generic framework will ever handle that.
What the heck has a framework to do with a specific application works? Any framework has no understanding on how an application works. It provides a scheme, philosophy and model to build upon. |
Additional note: Yes, I still have to pass repository access rights to someone, I'm unfortunately pretty busy with the liquidation of the PartKeepr UG. I hope I get around to that soon |
. |
In that case it actually might be better on reading up what Symfony provides and what not, instead of making false assumptions. There are no UI views generated by Symfony, at least not in PartKeepr.
Yes, you are misunderstanding things. Symfony provides no such things, maybe via some 3rd party bundle, but again, PartKeepr does not use such a bundle. Symfony is mainly used for the controller architecture, the serialization features (which, in conjunction, use the API platform to generate JSON-LD which then can be read by the frontend) and Doctrine for all database related stuff. |
. |
Reasons to use a framework, especially a widely used, adopted and maintained framework like Symfony2:
Up until PartKeepr 0.1.9, it didn't use a framework apart from Doctrine for persistence (Symfony2 didn't exist back then). Maintenance was a nightmare. The reason that there are no SQL injections in PartKeepr is because of Doctrine. The reason why there were so many new features after 0.1.9 in a short amount of time was Symfony2 and the API platform because of extremely low development overhead. The reason why PartKeepr works behind a reverse proxy without me writing zero code to support it: Symfony2. The reason why PartKeepr works on nginx without any code modification: Symfony2. If you have trouble understanding how Symfony2 works, no problem: There are plenty of resources on the web to help you out. If PartKeepr did use its own framework, you'd be very much on your own, even for the most basic functionality. I recently had a look at The Bug Genie as an issue tracker, and it doesn't use a framework at all - everything is self written. I submitted no less than 8 pull requests to fix bugs I encountered during normal use. After encountering half a dozen more bugs (and I only did use the software for maybe 30 mins over a period of a month), I stopped using it.
I can only guess: Relatively small user base and I did fulfill too many feature requests. It did work out of the box for the majority of users, so why would these users start contributing code?
Unless you are willing to learn how a software project and the underlying technologies work, not much. Stepping up and complaining about the choice of framework is a very bad first step. I will not participate in any project or development coordination in this project. |
i'm currently trying to update to symfony 3.4. if i make some progress i will give a update |
Hi @JelleDijkhuizen |
@martonmiklos, it looks like @adlerweb is trying to upgrade PartKeepr to Symphony 4 in a dedicated branch of his fork... :-) |
@ZupoLlask thanks for the heads up! |
I think this discussion was lengthy and the main issue is cleared out. See #1059. So, I will close this for now. |
"ETA" for new version of partkeepr :) ? someone knows something about it or project is already closed . I'm just curious
The text was updated successfully, but these errors were encountered: