The poll would be used as a mechanism to list all participants under clearly defined approaches (which is why it should be public IMO, and possibly allow multiple choices) - the number of votes for each option would be irrelevant.
(2017-10-10, 11:57 AM)sarisisop Wrote: [ -> ]I think most of this thread is only going to attract answers from people interested in the coding side of things, but you have to think of the end user because that is were your publicity is.
1.8 works, yes there are few niggles I would still like to sort but I don't have the skills or even want to play around too much with the coding but it works. It was also a nice update from 1.6 and the changes were very welcome, it's clean and simple to use but by what I have seen of 2 so far I don't see anything that would make me change.
I'm not saying dump 2, but as an end user with little knowledge of how the stuff works I just want to take it out of the box and use it without too much hassle.
I wonder how many copies of 1.8 are being used and how many are interested in 2 ? My thinking is that the end user (People like Me) would just like a few problems sorted if they effect us and get security updates as and when they are needed.
The
development of 2.0 was started mainly to address the overall low code quality causing all kinds of problems, starting with difficult maintenance - most of bugs are hard to fix because solutions are convoluted: there are numerous hacks, workarounds and poor structure decisions and changing them would result in rewriting major sections one way or another, resulting in numerous theme/plugin compatibility issues. The 1.x series don't receive major feature updates because it's currently technically inconvenient to adhere to rules that don't make much sense anymore.
After converting to rewritten software MyBB board owners would thus notice a long-term improvement of faster delivery of new features expected from a modern forum, pleasant & far-fetching theme customization, bug fixes and security patches (1.x releases usually happen once every few months - for that time all boards are theoretically vulnerable until updated, and updates can take a long time because security patches can be as complex as bug fixes due to code quality).
Any major upgrade between either 1.8 or further 1.x iterations and the first version of a fully rewritten software (current target is 2.0) would be accompanied by
1.x end-of-life deadlines (to encourage users to update, reduce maintenance burden and prevent most people from using dangerously outdated code) that are
adjusted to allow most plugin and theme developers to familiarize themselves with new techniques (more complicated, but easier once learned, especially with multiple examples), and possibly extended further if we notice the Community could use some more time.
As as direct consequence of better quality (i.e. code that doesn't need hand-guided documentation to avoid quirks)
plugin and theme maintenance (creation & updates) would be more encouraging to extension developers, and new Extend projects could be reviewed and audited faster (additionally, users could simply download the non-reviewed version directly from an extension's repository on their own risk, as that's where extensions will be hosted in 2.0).
Once most features are available in the rewritten version and can be easily converted to,
the burden would be reduced as much as possible and the upgrade would be similar to how it has been happening in the past: a web-based upgrade script that requires some information, some time to run the conversion and you shouldn't have to need the command line or switch hosting providers as long as the current one provides a reasonably up-to-date environment.
We are hoping to discuss the degree of how the 1.x series can be updated without spending too much time on code sections with death sentences already present (i.e. that would be ripped out and replaced with any major bump, like from 1.8 to 2.0).
Basing on today's state of discussion among developers,
the 1.x series could introduce theme-related breaking changes (resulting in minor plugin incompatibilities and 100% old theme incompatibility) for easier theming - making it possible to create responsive/heavily customized themes -
and strategic additions (code libraries, etc.) that would be used whenever some 1.x code is rewritten, with the main purpose of
bridging the knowledge gap between "simple" 1.x code and framework-powered 2.x code.