On 18 February 2015 at 00:28, Michael Babker <michael.babker AT 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).