Thread Rating:
  • 3 Vote(s) - 4.33 Average
  • 1
  • 2
  • 3
  • 4
  • 5
1.8 Next development steps ("1.10")
#1
Following the MyBB 1.x and 2.x Development RFC thread, and the recent release of 1.8.13, I think it's time to start discussing exactly what we want to see from the future of MyBB 1.8, heading into 2.0. I decided to start this thread to layout some of my ideas of what Id like to see and how we might approach this future.

This will be a slightly more technical thread, so don't expect screenshots of new themes or features or anything like that. None of this work has started, and the plans will change based upon feedback. Also realise that these are all just things I'd like to see and not the thoughts of the whole team.

Enhancements/Improvements
  • Introduce Composer for 3rd party dependency management. Currently all vendor dependencies are copied into the "inc/3rdparty" folder (such as the 2 factor authentication library). With Composer, we can more easily manage dependency versions and start making use of it's autoloader (and start introducing namespaces and autoloading into future MyBB code).
  • With Composer introduced, we can then start looking at 3rd party libraries that could benefit the software. Some of these include:
    • A dependency injection container, such as Pimple.

      This would go well with introducing other third party components into MyBB, allowing plugins to overwrite and extend defined services easily.

      Pimple itself is extremely well tested, has been around for a long time and has a great set of features.
    • Twig - a PHP templating language/library. This would provide much more flexibility and power when creating templates - it allos for conditionals within templates, loops within templates, and more.


      The introduction of Twig would be phased, with the Administrator Control Panel being the first area of the softwae to have it introduced. In current versions of MyBB, the ACP uses hardcoded HTML inside the PHP files to output content (and a Form/Table class to manage forms and tables). Introducing Twig here would help clean up the ACP and during the introduction we could look at the layout and styling of the ACP to improve it's usability.

      After introducing Twig to the ACP and people getting used to the way that it works, we can then start to look at introducing it into the front end of the software. This would obviously be a much bigger job, but would prove worthwhile in my opinion.
    • Swift Mailer - a email library for sending emails in both text and HTML formats, with features such as attachment support, better compliance with different email servers and more transport mechanisms.

      MyBB 1.8.13 made an effort to fix the way that MyBB sends emails in some places (such as the contact form), but the current mailhandlers could be improved with the introduction of a well tested component such as Swift Mailer.

      This should be relatively easy to implement, as all emails within MyBB that I'm aware of are sent using the "my_mail()" function, presenting a single entry point from which we can introduce Swift Mailer.
    • A caching library, following the PSR-6 standard. MyBB already features a couple of caching classes in the core, but offering option for more caching systems (such as Redis) could be extremely useful. Rather than reinventing the wheel, using a 3rd party library that follows a defined interface (PSR-6) should offer more flexibility and options.
    • A routing library, particularly for the Administrator Control Panel as the first stage. The ACP currently uses it's own front controller style of dipatch to modules based upon the URL. Introducing a proper routing library here would be the easiest place to start. Eventually this routing library could be transitioned into the rest of the software, though that is a much larger goal.

      In terms of the actual ruting library, there are many. My preference would be something like FastRoute, which is billed as being fast.

      Combining a router with a middleware system such as zend-stratigility would allow us to build composable modules with middleware being easily managed by plugins to provide additional functionality such as easy permission checks.
    • A PHP based Command Line Interface for installing, performing ugrades and other maintenance tasks. The Symfony Console component is pretty much the gold standard of libraries for writing command line applications in PHP. The CLI should be easy to extend by plugins to add more commands and options.
    • Introduce an internalisation library for handling translations, offering more power to authors of translations. Translations should also be versioned better to allow the easy upgrading of language packs and for users to realise when language packs are out of date.

Approach

Currently the core MyBB repository has two main branches:
  • master - The code from MyBB 1.6, which hasn't been touched in 2 years.
  • feature - the current code for MyBB 1.8, in active development.

One possible new set of branches would be:
  • master/1.6 - the code from MyBB 1.6.
  • master/1.8 - the code for the most recent stable release of 1.8.
  • develop/1.8 - the code for the verison of 1.8 currently in development, but not yet released.
  • develop/1.10 - the code for the in development version of 1.10.

Once 1.10 was released, a "master/1.10" branch would be introduced, containing the most recent stable release of 1.10.

One consideration here is whether the "master/1.6" branch is needed at all. All releases are tagged with a release version, so old stable released versions can be downloaded using these tags.


Again, these are all just my current thoughts on the future direction. Some changes are fairly easy to implement (caching system changes, introduction of Swift Mailer), some are more difficult (completely changing the template system for the front-end). Once we reach something resembling an agreement of what we want and how we want to approach it, we can start looking at assigning tasks and starting the development process.
Reply
#2
(11-11-2017, 02:12 PM)Euan T Wrote: One possible new set of branches would be:
  • master/1.6 - the code from MyBB 1.6.
  • master/1.8 - the code for the most recent stable release of 1.8.
  • develop/1.8 - the code for the verison of 1.8 currently in development, but not yet released.
  • develop/1.10 - the code for the in development version of 1.10.

I feel this should be more like:
  • master – lastest stable release at all time regardless of version (in other words until 1.10 is released as stable, 1.8 would be here)
  • minor (or feature or whatever) – minor point upgrade in progress for the master branch (in other words, 1.10 would be here until it is stable)
  • patch (or maintenance or whatever) – maintenance/patch point upgrade for the master branch (1.8.x [currently 14] would be here)
  • 1.8 Patch – would be created after 1.10's stable release as 1.8 should be feature-locked at that time and wouldn't need a minor point release branch

EDIT: And I don't think we need a branch for 1.6 at all, but if it is insisted upon then a branch named archive-1600 or the like would suffice.
Reply
#3
(11-11-2017, 05:32 PM)Wildcard Wrote:
(11-11-2017, 02:12 PM)Euan T Wrote: One possible new set of branches would be:
  • master/1.6 - the code from MyBB 1.6.
  • master/1.8 - the code for the most recent stable release of 1.8.
  • develop/1.8 - the code for the verison of 1.8 currently in development, but not yet released.
  • develop/1.10 - the code for the in development version of 1.10.

I feel this should be more like:
  • master – lastest stable release at all time regardless of version (in other words until 1.10 is released as stable, 1.8 would be here)
  • minor (or feature or whatever) – minor point upgrade in progress for the master branch (in other words, 1.10 would be here until it is stable)
  • patch (or maintenance or whatever) – maintenance/patch point upgrade for the master branch (1.8.x [currently 14] would be here)
  • 1.8 Patch – would be created after 1.10's stable release as 1.8 should be feature-locked at that time and wouldn't need a minor point release branch

EDIT: And I don't think we need a branch for 1.6 at all, but if it is insisted upon then a branch named archive-1600 or the like would suffice.

Seems like naming changes only, which should follow some wider standard - the suggestions from Slack follow the concept described at https://gist.github.com/dvz/eca6ba94dded...66e45fbe3d, i.e. Gitflow.
Since we're planning to maintain 2 stable series simultaneously each should have a master/* branch to hold stable code (which will be downloaded from repositories directly by tools and dependency managers).
minor is usually develop or feature - 1.8, while feature-locked, would still receive numerous bugfixes (as it does now); patch would be either hotfix/* (release-specific, merged directly into master and merged back to the development branch) or release/* (derived from develop and merged to master).

Once a stable series reaches EOL the next one's branches could be renamed simply to master develop (1.8 stable code might as well be merged into master after each relase) but keeping the version suffixes could prevent mix-ups, especially that the future of each series will become less certain.

I don't see downsides to dropping the 1.6 branch altogether.
devilshakerz.com/pgp (DF3A 34D9 A627 42E5 BC6A 6750 1F2F B8AA 28FF E1BC) ▪ keybase.io/devilshakerz
Reply
#4
(11-11-2017, 06:13 PM)Devilshakerz Wrote: Seems like naming changes only, which should follow some wider standard - the suggestions from Slack follow the concept described at https://gist.github.com/dvz/eca6ba94dded...66e45fbe3d, i.e. Gitflow.

How do you see my suggestion as "naming changes only"? What I am suggesting is that we stop putting our latest release in the feature branch and follow the standard which is to have the latest release in master at all time-- not to have two or three master branches, but one single branch. When 1.10 is released as stable then an archive and patch/maintenance branch should be made for 1.8-- it is that simple. The second that 1.10 is stable, 1.8 is on a clock to extinction and we should think that way from here on out. Starting with the removal of 1.6 from the repo-- as Euan mentioned tags exists so there is no point in keeping the branch alive.
Reply
#5
(11-11-2017, 10:12 PM)Wildcard Wrote:
(11-11-2017, 06:13 PM)Devilshakerz Wrote: Seems like naming changes only, which should follow some wider standard - the suggestions from Slack follow the concept described at https://gist.github.com/dvz/eca6ba94dded...66e45fbe3d, i.e. Gitflow.

How do you see my suggestion as "naming changes only"? What I am suggesting is that we stop putting our latest release in the feature branch and follow the standard which is to have the latest release in master at all time-- not to have two or three master branches, but one single branch. When 1.10 is released as stable then an archive and patch/maintenance branch should be made for 1.8-- it is that simple. The second that 1.10 is stable, 1.8 is on a clock to extinction and we should think that way from here on out. Starting with the removal of 1.6 from the repo-- as Euan mentioned tags exists so there is no point in keeping the branch alive.

That's the plan. master/1.8 might appear more obvious than patch for people looking for stable 1.8 code and whenever a branch is renamed or moved all links and Pull Requests break, hence version suffixes.
devilshakerz.com/pgp (DF3A 34D9 A627 42E5 BC6A 6750 1F2F B8AA 28FF E1BC) ▪ keybase.io/devilshakerz
Reply
#6
(11-11-2017, 10:34 PM)Devilshakerz Wrote: master/1.8 might appear more obvious than patch for people looking for stable 1.8 code and whenever a branch is renamed or moved all links and Pull Requests break, hence version suffixes.

The naming suggestions I made weren't meant to be taken too literally. Suffixes are fine and as I mentioned, 1.8 would obviously need its own stable branch.

I am opposed to having any sort of suffix on the master branch, however. The assumption that master = latest release should be fostered and kept as the default on all open source projects.
Reply
#7
MyBB 1.6 branch is a historic record, it shouldn't be removed.
Software Engineer specializing in Crystal Program Development

Reply
#8
At work, my team needs to support multiple versions of our product. Based on my experience, I suggest the following:

master => latest stable released version; commits on this branch are tagged
develop => development for the version to be released next

x.y-master => latest stable released version of the x.y series; only created if a patch is needed
x.y-develop => development branch for the x.y series

The big benefit over Euan's suggestion is that "master" is always the latest and greatest stable version.
Reply
#9
(11-14-2017, 12:10 AM)laie_techie Wrote: master => latest stable released version; commits on this branch are tagged
develop => development for the version to be released next

x.y-master => latest stable released version of the x.y series; only created if a patch is needed
x.y-develop => development branch for the x.y series

The big benefit over Euan's suggestion is that "master" is always the latest and greatest stable version.

Exactly.
Reply
#10
(11-13-2017, 11:42 PM)Lunorian Wrote: MyBB 1.6 branch is a historic record, it shouldn't be removed.

The current feature branch builds upon the current master branch. Removing the current master branch (1.6) doesn't result in any loss of history whatsoever.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)