This post is a summary of a discussion which took place at the Neos code sprint in Vienna.
- packages which are included in the distribution
- they have to be compatible with the old and the recent releases
What Flowpack is, will be told by the new website. If you are interested, have a look here:
Additionally we talked about a set of rules that should apply to
Flowpack packages and in extension also to
Neos packages which are handled even “stricter” obviously.
This are the first rough ideas:
Possible Flowpack Rules
- Follow Neos coding guidelines
- Should provide versions working with all maintained Flow/Neos versions (within time X after release)
- have tests and test automation
- package is considered stable and has been in use before moving to Flowpack
- at least one team member constributes
- Security maintenance
- Contact person/group defined
- At least very solid readme to describe installation and getting it running as well as options
All the unmaintained packages are now archived on Github
And good progress with the new flowpack.org website, the minimalistic version should be online tomorrow.
great initiative, thanks for working on this topic!
As already mentioned before, I would like to see general guidelines about the repository names as well. We currently mix
Obviously there are more important things, especially when you work exclusively with composer. But as you’re on it…
@samuel.hauser continue to work on it today by adding basic content page support and showcase the list of Flowpackers and contributors list for each package.
Yes composer-name all the things. Down with package keys!
I agree. So we should go for the regular composer directory structure in the long run as well, right?
That would be the end goal. I would probably first want to see if we can allow composer names in stuff like routes and such.