• 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.
    

• 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.
  

• 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.
  

(2017-11-11, 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.
  

• 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
  

(2017-11-11, 05:32 PM)Wildcard Wrote:

(2017-11-11, 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.

(2017-11-11, 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/eca6ba94dded641dfa98e766e45fbe3d, i.e. Gitflow.

(2017-11-11, 10:12 PM)Wildcard Wrote:

(2017-11-11, 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/eca6ba94dded641dfa98e766e45fbe3d, 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.

(2017-11-11, 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.

(2017-11-14, 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.

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