Post by Wild1145 on Jun 18, 2020 21:17:31 GMT
Beta - This is where I think we probably need some clarity on how the development process is going to work. If we are going to maintain the process of 'Cutting a release', this works fine, we keep pushing the beta branch on to the server as we please and only then cut a formal release when we're happy with it, until then everything lives on 'Feature branches' which are that 'Experimental' category. If however you want to move to a more 'Continuous delivery' model, it may be prudent to drop the idea of a beta branch and use the beta server to test specific branches of the plugin before they get merged into the public branch. Both are valid ways of doing things, I think it would be worth clarifying.
Public - I think we would like to get this automated, or at the very least to a better state of 'Versioning' the server, this could initially be done manually with things like release notes and instructions for example, but automation should be our target. With regards to converting data types and files, I think historically the decision has been taken that the plugins should be able to handle this (You'll still find the legacy Username's --> UUID Conversion logic somewhere in TFM just in case you are still running a really old server), so I'd really say we should never be manually changing data files, especially for concerting file formats, it's just a bad idea in general and breaks the DevOPS Modeling.
Custom Plugins: I agree, I think there is going to be a need to have forks of plugins, we don't want to be maintaining more functionality than we have to, but as you say we should not be fixing their bugs (Or if we do let's PR it back to them so at least it's fixed once and we don't keep re-patching it), but I think it will make sense to use other plugins.
For custom plugins, the best route is to go upstream and PR changes to avoid having to maintain forks and also for the courtesy of fixing something upstream. However, we have our own type of changes we need to put into some plugins, and that may necessitate custom forks. When we do that, we should make sure that we're properly synchronized with upstream for releases to avoid catastrophe.
The thing is there's a lot of ways to do it, and there is no clear cut answer. I'm running projects at work and for my own company and just about every project does things slightly differently because it makes more sense for them. In reality we don't need a fully end-to-end automated smart system, there are plenty of ways in which you can do CI/CD in a fairly rational and sane way, it just is about the direction Seth wants to go down, personally given MC is version tied I tend to find doing versions for plugins makes the most sense, but you don't have to. At the point you're doing versioning, Github handles version tags and such natively when you 'Cut' the release.
Where we store our data is semi-irrelevant for the sake of this conversation, my point stands regardless of how you store data, because even data in databases need to be re-indexed / re-potted from time to time, hopefully that can be automated, and should be unless it's just not technically possible to do so.
And yes, that was the point I was trying to make with custom plugins, maybe not all that well.