Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-frame...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.
Please pardon any errors, this message was sent from my iPhone.
Will the CMS use this new version of the Framework? I know that ideally both should dovetail but ultimately, is it the CMS or Framework that will take priority if there is a conflict.
2. Ability to fulfill the db with fake data
3. CLI app for creating app scaffoldings
## Consolidated Code RepositoryI personally don't think this is optimum. While, sure, it makes checking out the Framework easy, it does complicate matters.It doesn't promote isolation of the code (we've had cases where tests passed in the full stack, but didn't on an individual package because some test scaffolding bled into other tests).It makes the tests for each package longer to run (if I want to make a quick fix to Keychain, I have to wait for all the other tests to run first).It doesn't allow for incremental changes to individual packages to happen when they are needed (for example, many packages could go 2.0 right now, but it's not happening because some packages are not quite ready).My personal preference, and it's come from working in both the Composer and NPM universes, is that individual package are the point of truth, manage their own dependencies (the less the better) and their own lifecycle (some packages will get a lot of support and change a lot, some won't - so be it).In terms of being able to download the whole Framework, this can be done with Composer's create-project feature. In fact, you don't want to do that at all. You want to spin up a half-dozen examples of starter applications (command line, REST, web site, et al) that people can pull down and have a skeleton application up-and-running very quickly.
## DocumentationGiven the previous comment, I feel strongly that documentation should still live with each package.However, the intention was always so be able to build the programmers API into one site (from the DocBlocks), and also compile all of the package documentation into one master site (something like what Laravel does would be what I would aim for).The advantage of leaving the docs in the same repo as the code is that you only need one pull request to check that the documentation has been adjusted appropriately for any given code change.To put it another way, it's easy to automated collecting docs from several sources. It's not easy to automate checks that there is a PR for code (and tests), and a PR for docs. The split strategy has never, ever worked for the CMS, but having docs and code in one contributor PR has worked in the Framework for many years.
On 18 February 2015 at 00:28, Michael Babker <michael...@gmail.com> wrote:
> Some of my griping about the current structure is based on how disconnected
> everything feels
It should if you are adhering ruthlessly to the Single Responsibility
Principle. That's actually a really good problem to have :)
> and how difficult it is in this structure to get attention
> around updates. Since Framework 1.0 was released, there have been a grand
> total of zero announcements regarding package updates.
I believe I sent in PR to move Keychain to 2.0 some time ago ;)
> Granted, it's as
> much my fault as anyone's (if not more), but it's really difficult to
> promote package releases when effectively what we're doing is "hey, we
> merged a pull request, here's an updated package!". I doubt anyone wants to
> see 3 dozen "Framework <Package> 2.0 Released" tweets,
No, that's not what I'm thinking at all, except perhaps for day 0.
After that, each package is master of its own destiny, which may
include bumping major versions from time to time, or accepting that
its season of usefulness is at an end.
> nor would it do well
> for us to have a single "Framework 2.0 Released" announcement when a
> majority of the stack has had 2.0 for potentially weeks or months (the
> DateTime package from last year's GSoC was released as 2.0 in September with
> no fanfare). The only unifying thing about our present structure is the
> brand name, and I'd go so far as to say what we have isn't framework
> material nor is it being managed in a way where it could be considered such.
No, and I think a mindset change is needed. The overriding fact is we
are never going to have the resources to do a full-stack framework -
and that's mostly due to the fact that we have no major corporate
users to back the Framework up.
To solve that, I think you need to change tack and use the Framework
to upgrade the CMS one package at a time, using a 1.5-style legacy
layer to bridge the changes. That way, the CMS is using the code and
there is no stupid argument about whether the Framework deserves to
have the name Joomla.
Yes, that was how Platform 11.1 was supposed to work but the problem
with that was the monolithic release system. Composer support for the
CMS fixes that, but I still think trying to synchronise the versions
of 30 packages, where there is mostly no change in any of the
packages, is a messy system to support.
If you go fully modular, a bug fix for a package can be merged and
released on the same day - simple! And semantic versioning is easy to
work out. The alternative, which is the current situation, is PR's
wait until you get to a point where you "feel" like a release is
needed, or you are constantly argue to delay the release to slip in
another fix. Why not just fix each package and bump the package's
version when you need to?
>> ## Documentation
> (https://github.com/laravel/docs) and Symfony
> (https://github.com/symfony/symfony-docs) both maintain docs in a
> consolidated location on GitHub and publish them via their main website.
Yes, and both of those projects have solid companies backing them so
they have the resources to maintain superb docs. They are also mature,
full stack offerings. The Joomla Framework isn't anywhere close to
being able to claim that. When the CMS is entirely built off Framework
packages, we can revise the status :)
Anyway, the extra docs you talk about go into the framework.joomla.org
site itself, separate from the individual package docs. That site
aggregates both the PHPDoc API pages and also package docs themselves.
That way, the rules of contribution are simple:
1. The developer MUST include DocBlocks (that pass linting rules).
2. The developer MUST provide explanatory notes about the basic usage
of the package with the PR.
3. The developer MAY choose to add additional user tutorials for one
or a combination of many packages.
At the end of the day, I could live with docs all in one repo,
providing reviewing strictly enforces that docs are a requirement with
code changes. But, I think a solid README is still vitally important
for the developer doing a search on Packagist.org and coming to the
package on Github and finding out what it does. If Packagist follows
the NPM example, it will eventually start consuming, and potentially
indexing that content (at least, that's what I'd do).
### DocumentationDocumentation is essential for every piece of code, even if you have a big brand like "Joomla". And if Joomla-FW separates the documentation and code, it will be the same mess like Joomla-CMSs documentation. Having documentation and code in the same repository doesnt't mean that there can't be another repository for global documentations like tutorials or guidelines.
### Minimum Supported PHP Version
Definitly 5.4 or even 5.5
### Database / FilesystemThere are plenty other packages which are doing a great job (e.g. doctrine or flysystem), but a stable framework should use his own api to be flexible. So why not creating a persistence api like Typo3 Flow ?
### Consolidated Code Repository
The current amount of packages is rediculous, indeed. But instead of throwing everything in one repository, we should have one repository for each logical block. MVC is a good example.
The Joomla! Framework™ is a new PHP framework (a collection of software libraries/packages) for writing web and command line applications
Now i'm confused. Were there any plans to not offering install-packages separately ? If there were plans, and please excuse my wording, it would be ridiculous and against everything (composer, PHP-FIG, etc.) the PHP community worked for in the last year(s).Back to the roadmap: Will "Joomla Framework" be a part of GSoC 2015 ? Some goals of the roadmap could be "outsourced" to students.
Well, i think you are more up to date with the current progress. But the form package could be something for GSoC, or the social packages if the http package is ready.
Doctrine DBAL seems like it might be a good candidate for consideration as it is an "Abstraction layer and access library for relational databases. A thin layer on top of PDO with a lot of additional, horizontal functionality."
This would fill some of the holes