davidsneighbour
commented
4 years ago Opinions here, not facts ;)
I know plugins/systems that use the fixed-release-cycle method to get out versions more often. I think it's a bad idea in sense of having a binding date for a minor or major release version. I always find Yoast SEO's release cycles funny ;) "Let's introduce a new minor version because the old one is two months old!". It's absolutely ok to release patch versions often. The only problem with "release often" is, that if those patch versions fail the end user in sense of introducing bugs instead of fixing them will tire them of updating often. So we need an absolute "failsafe" way to do code and feature testing. Once the trust is broken we will have a hard time arguing for the end-user to install "yet another update".
A release calendar forces us to sometimes have "pretend" releases. I much prefer to release each time we fix a bug (patch release), have a minor release on new features and a major release on breaking changes.
Regarding the splitting: I was looking over the embedding classes today and we have open tickets where in sub-sentences we hear that embedding multiple times (more than one theme or plugin is using Colossus) fails. There are ways to mitigate this, but It opens up more than "which plugins/themes colossus are we using"... for example if versions differ or breaking changes are introduced.
All in all from a programmers point of view we can have a plugin and an embedding class. The plugin will need interfaces so people can add option pages and structures via an interface, the embedding plugin would just use the core Colossus system to parse developer-defined arrays of setups. I would implement this via a composer package system. It makes sense.
I always embed Colossus (well, ehm, Titan Framework) in my themes, because a plugin might get deactivated by a well-meaning end-user that does not know it's used.
Let's think about this... maybe it's "just" a line of code that we need to document properly instead of separating and clustering code.
codeclinic
Whenever I tried adding Titan as an Embedded part of my plugins, it just never worked. Titan was often unavailable to my scripts and this seemed to be sporadic. I had similar issues when referencing Titan as a standalone plugin, but it worked much more reliably than the embed method.
On the other hand, I had lots of feedback saying from people saying that they were outraged at having to install a separate plugin (Titan) just to use my plugin. As Titan got abandoned and the last update got further and further away people got even more angry and started suggesting that it was a huge security issue and that maybe my plugins were some sort of malware.
Regardless of peoples reasoning, I know it cost me a lot of users and ultimately customers for my plugins. To the point where I've essentially stopped development on them until I could find time to rewrite them using a new Framework. Luckily we now have Colossus WP Options Framework!
So....
My question is do we want to split releases into two clear installation paths ? So we would release an Embed version and the Plugin version, so as to make it easier for people to use one method or the other. If I recall correctly using the Embed method required you to remove some files and place things in the right folder etc. I know it wasn't a huge task but would we make it easier for people to Embed by Saying "Heres the Embed release, just drop it in X folder in your theme and then add this line to your functions"?
Do we even want to encourage people to use the embed method?
In terms of the plugin version -for the reasons mentioned above- we should try and keep releases on the WordPress.org directory frequent, so that it always appear up to date. However, I know WP rules states that you shouldn't submit plugins with a fake version bump. There should be actual updates to the code in every official release.
Perhaps we need to have a release schedule. That way we can always have a release every x weeks / months no matter how big or small the changes made.
Thoughts?