View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 3843 | Composr website (compo.sr) | General / Uncategorised | public | 2019-06-28 20:18 | 2025-02-27 16:40 |
| Reporter | Chris Graham | Assigned To | Guest | ||
| Priority | normal | Severity | feature | ||
| Status | new | Resolution | open | ||
| Summary | 3843: Review documentation talking about feature planning and release cycles | ||||
| Description | In the past we have worried about compatibility-breaking changes in new versions, so delayed the pace of major versions, to give people's themes a good life span. v11 will move to more of a "rolling release" / "release early, release often" kind of philosophy. At least, that's what I have in mind. This is partly due to a couple of major changes coming in v11 to support it: 1) A new philosophy of the default theme being (necessarily) much more complex out of the box, and also made with much more configurability. Web design has moved on a long way, and editing CSS is now far beyond the skillset of the average user, as well as now being perceived as a very technical thing. So fewer and fewer users are going to want to make custom themes, which is the main issue regarding compatibility. Also, very few Composr/ocPortal themes have been released historically, due to the scope of the product (investment requirement in making a good theme), and people wanting to keep their themes personal to themselves. So supporting third party theme compatibility is not really a concern. 2) Automatic upgrades. For those users who will have highly customised Composr code, most will fit into 3 camps: 1) Users who can put their customisations directly back in core, with getting them without need for overrides as soon as the next patch release. This is a big win, as it moves more people to core development. 2) Users who can put in occasional time tuning things as compatibility drifts. 3) Users who can pay a company to maintain a 'long term release version' with whatever security and stability patches that might be needed and/or pay experts to manage the upgrades. The particular arrangement would really depend what service companies are willing to offer. For example, a company may provide a fixed-cost upgrade service, so long as that company is the only company allowed to create code/theme-file overrides in their site (to avoid surprises). Obviously there are positives and negatives with this new approach. The negative would be the need to stay on top of compatibility changes just to keep Composr patched, if you happen to have a customised theme or overridden code (or pay a lot of money to have patches backported for you). The positives though include getting the latest features much faster, and Composr versions not getting stuck in increasingly protracted development timelines (due to the increasing difficulty of leveraging the benefits of a pattern of making big releases). It should add a lot of momentum and excitement to the community, and make development much more fun and less stressful. I believe this change rebalances things to benefit the average user better, while the more technical user will likely have the capacity to deal with the situation adequately. It definitely makes a big change to how the community works - rather than all hobbyist and corporate users having their needs met with a single free release process, it splits it in two - which I think is financially much more viable. Enterprise users will need to bring in money to fund their enterprise requirements, while for the average user things will get a lot more fun. Our documentation needs reviewing to make sure it is accurate to the new philosophy. It should: a) explain it's the themers responsibility to check for compatibility changes when upgrading b) explain that automatic updates should likely be disabled if custom themes are installed c) tone down discussion of the complexity of planning when features can be released (tut_software_feedback) d) Any overrides done by developers should have the purpose of the override clearly documented as a comment in the override (with the version the override was last synced with). This should be mentioned as a coding standard (codebook_standards). | ||||
| Tags | Roadmap: Over the horizon | ||||
| Attach Tags | |||||
| Time estimation (hours) | 3 | ||||
| Sponsorship open | |||||
| related to | 4253 | Resolved | Chris Graham | Composr | Standardised documentation files |
|
|
Review the .md files (made with 4253,) and move some of the text into official documentation linked to by the .md files. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-06-28 20:18 | Chris Graham | New Issue | |
| 2019-06-28 20:18 | Chris Graham | Tag Attached: Roadmap: v11 | |
| 2019-06-28 21:36 | Chris Graham | Description Updated | |
| 2019-06-28 21:37 | Chris Graham | Description Updated | |
| 2019-06-28 21:41 | Chris Graham | Description Updated | |
| 2019-06-28 21:44 | Chris Graham | Description Updated | |
| 2020-03-07 21:21 | Chris Graham | Assigned To | => Chris Graham |
| 2020-03-07 21:21 | Chris Graham | Status | Not Assigned => Assigned |
| 2020-06-02 01:47 | Chris Graham | Note Added: 0006572 | |
| 2022-11-20 03:00 | Chris Graham | Tag Detached: Roadmap: v11 | |
| 2022-11-20 03:00 | Chris Graham | Tag Attached: Roadmap: v12 | |
| 2022-11-20 03:06 | Chris Graham | Assigned To | Chris Graham => |
| 2022-11-20 03:06 | Chris Graham | Status | Assigned => Not Assigned |
| 2023-02-26 18:29 | Chris Graham | Category | General => General / Uncategorised |
| 2024-03-26 00:58 | PDStig | Tag Renamed | Roadmap: v12 => Roadmap: Over the horizon |
| 2025-02-27 16:40 | PDStig | Relationship added | related to 4253 |
