Sheet Versioning

I just started collaborating at fixing bugs in a character sheet and after the first pull merge was accepted my players are asking "those" questions about when the fixes will be live... So I combined their doubts with my own and I thought to post them here. I'm assuming that there must be somekind of QA going on between a merge happens and the new version is "released" to the whole Community so: -1) Are changes derived from pull requests merged notified somewhere when they go live? (like the changelogs on the Official Sheets) -2) Is there any necesary step to "convert" existing sheets when new changes go live? -3) The particular sheet we are using (RunequestGQS) has a visible version tag that uses a "release date" approach. Who is expected to update those version fields (that can help users to distinguish when a new version is published)? In the pull request I added I didn't include changes there as I expected to be updated on each "release" after a potential QA cycle (that I suppose contains the result of múltiple merges). Thanks in advance for the clarifications, because most likely my group will keep on using this fantastic sheet and we will keep creating pull requests to fix whatever bugs we may discover and would rock to know all of this details before we create the next pack of fixes.

Roll20 doesn't perform any QA on community sheet updates, just check that the PRs seems sensible. Roll20 goes through the PRs on Monday/Tuesday and if approved, usually merges them after approval. Then on Tuesday/Wednesday when Roll20 does their other updates, the also push to live the community sheet updates. 1) Nobody is notified, but community sheet updates usually coincide with official sheet updates and other general Roll20 updates performed on Tuesdays. There is usually a forum post with the official changelog posted when things go live, from which you can suspect the community sheets also have been updated. Edit: Seems this weeks' changelog/forum thread was just posted 2) No. So official and some community sheets have opted to create sheetworkers that performs updates based on versioning, but that's fairly rare and not expected. Only needed if attribute names or structure have changed. 3) Nobody is expected to do anything. But it sure is easier to see at a quick glance if/when a update have gone through if a visual sheet versioning is used. I use sheet versioning in that way, but don't have the changelog integrated to the sheet in the way the GURPS sheet have, I'd eventually try to do it like that so that users can see the changelog from inside the game with a notice, and then just turn it off. Edit:  I see you don't have a Pro account, how do you test the changes you made? Testing the changes before submitting the PR is a prerequisite.

pepedespota said: -2) Is there any necesary step to "convert" existing sheets when new changes go live? To add to Andreas's exccelent answer: sheets are not converted in any way. The old version is simply removed and the new version replaces it.  This means any changes in attribute names can cause data loss to users of those sheets since they wont understand why their data has gone.  This is why sheet designers generally includesheet workers to update a sheet's data if they have made changes that require it. But most changes to a sheet's code dont need this. A character's attributes are stored in an external database, and will be loaded whenever the sheet loads. This means that you can completely change everything about a sheet, and as long as you leave the attribute names intact, you dont need to do anything to handle the changes. The system will manage it automatically.

Thanks for the fast and detailed answers. The doubts were not about how sheet code works, which is preatty straightforward to see and test by simply inspecting existing sources in the repository and using the standard dev tools provided by Chrome or Firefox, but about a potential internal review process after the merge is accepted and the changes go live (Typically on the following Tuesday, as I have read). The doubts are now dissipated thanks to both answers. I will hold further bug fixes until I decide if PRO sub is worthy or not... Didn't knew that "testing" automatically implided "tested by a PRO account" in this case. If the first BUG fix pull request has breached any TOS... I will request its removal ASAP.

This is exactly why I suggested reaching out to people actively working on the (I will refrain from using the term you used to described it on Github) sheet and then you would have been informed about the process.     There is no review process beyond the Roll20 employee checking for things like line endings, table use and conflicts. Also I, or someone else with a PRO account, could have tested the changes since you don't have a one. 

pepedespota said: Didn't knew that "testing" automatically implided "tested by a PRO account" in this case. You can't fully test code without running it as a custom sheet inside Roll20, or use the Sheet Sandbox. Or are you saying you'd submit half-tested code to be put on live? Considering the once-a-week update frequency, that would not be a cool move. Roll20 only performs midweek updates if a sheet might completely broken, but that's not given when it comes to community sheets. The point is that we properly test our-self what we submit.

Sigh... No problem, you will not have this "issue" again with me personally, at least.

You can ask if there are pro users who are willing to host  test game for you to test things.

Sorry but that time has passed... I have sat here patiently here atonished at been: - Bullied - Questioned about my developing/testing practices - Insinuated that my intention was to break code that other ppl contributed beforehand. And all of the above after 2 days with a BUG Fix applied that is working flawlessly with 0 errors and that fixed EXACTLY what it was announced, applied over code that has been "tested by a PRO account" and that shown clear FLAWS on the source code left roting there for months and that my team of players took less than 35m to discover it had discrepancies with RGA Books in a specially important aspect of that ruleset. I'm been unfair with David, the original author (hopefully I will "fix it" in a few lines), because ANY1 that earns his/her living programming knows this simple rule: "The only way to not trigger a Bug... ...Is to NOT code" And his job on the sheet in question and the one it's based on (RQ3 one if my initial analysis on code style is not too far off) is quite good... So saying a simple fix (less than 20 effective lines) like mine lacks bugs compared to his MASSIVE work is been a cynic... ...But I wanted to point the deep paradox of asking some1 that just delivered code that works that have to use (and pay for) the same TESTING APPROACH that didn't prevent the very same bugs the pull request addresses. If this is the way this Community greets new collaborators... well, it needs some "work", to say the least. To David: Your job with RQ sheet is very good, and my intention was not to discredit nor harm how it works here, but helping at improving it... Knowing that probably will be less than 10 groups the ones actively using it (The only explanation I can find for those bugs to be overlooked for so long) is a testimony of the dedication old time RQ players show. Just a friendly advice from a Developer by trade... My initial impulse was to refactor the way your code evaluates skill mods taking advantage on how the mod tables work... In reality there are just 2 numeric relations between a stat and the bonus it provides so every single skill mod can be evaluated as: categoryMod = PrimaryStatMod(<stat1>)+-PrimaryStatMod(<stat2>)+-SecondaryStatMod(<stat3>)+-SecondaryStatMod(<stat4>) If you add into PrimaryStatMod() and SecondaryStatMod() the right progression, your actual code could be reduced to 20% of the current size, it will be more readable and extendable and above everything else, it will not show the mistakes of the hundreth copy'n paste operation performed at 3 o'clock in the morning so common when you dedicate your FREE time for COLLABORATIVE work after a lenghty day of work.

I know it's not the that great that people can't easily contribute to community sheets, and that's why I'm pushing for the suggestion on the Suggestion forums(sorry can't find it right now). Yeah, over the years I've fixed bugs on several sheets that have been there for long until someone reported them, and I've seen people make PRs with updates to sheets that have broken basically everything on it, due to it never being tested. But most importantly, when I started with character sheet stuff, I submitted a small sheet update that I didn't test, and got plenty of hate for it and criticism . I'm trying to mention things that I'd like to have heard myself beforehand. So while I'm not always on point with the tone of my message, this specific thing comes from a place of experience and care. I 100% know you're not intentional trying to break any code, but you know what I'm getting at with the thing about untested code. Roll20 have a ton of quirks and things of which only parts are documented (if which I've done a good bunch), so even a good dev environment won't be the same as having it tested in Roll20. And yes, there are plenty of bad implementations, much that could do with refactoring, some include some of the sheets I'm the active developer for. That being said, I can host a test game for you for whatever you were working on, and update it when I'm available, or you can ask someone else if you feel communication was off-putting so far.

I'm sorry, but characterising the responses you've recieved this way is a little ridiculous: pepedespota said: Sorry but that time has passed... I have sat here patiently here atonished at been: - Bullied - Questioned about my developing/testing practices - Insinuated that my intention was to break code that other ppl contributed beforehand. None of that has happened. What has happened is a grand total of TWO people have pointed out that pushing updates to roll20 sheets without testing them in Pro is unwise, while also offering to host campaigns for you so you could do that testing. It is definitely true that pushing updates to roll20 without testing them in roll20  is unwise: people have covered some reasons why, but another is the simple fact that the roll20 devs themselves dont actually do any QA testing: they basically take it on faith that the submitted sheets will work, and handle it afterwards if they break. And that's the only practical thing for them to do - they are a small staff and there are so many submissions each week they cant test them all. So that means people have a strong preventative mentality: try to do everything possible to make sure that something isnt going to break, before it's submitted. And one of the easiest ways for things to break is people submitting changes while not being familiar with roll20's differences and limitations.  That's also why people generously offered to host campaigns for you so that you could test ahead of time. There was no bullying here.

pepedespota said: Just a friendly advice from a Developer by trade... My initial impulse was to refactor the way your code evaluates skill mods taking advantage on how the mod tables work... In reality there are just 2 numeric relations between a stat and the bonus it provides so every single skill mod can be evaluated as: categoryMod = PrimaryStatMod(&lt;stat1&gt;)+-PrimaryStatMod(&lt;stat2&gt;)+-SecondaryStatMod(&lt;stat3&gt;)+-SecondaryStatMod(&lt;stat4&gt;) If you add into PrimaryStatMod() and SecondaryStatMod() the right progression, your actual code could be reduced to 20% of the current size, it will be more readable and extendable and above everything else As it happens, I have code on the wiki that could be used in the RQG sheet to universalise the skill category modifiers calculation: <a href="https://wiki.roll20.net/UniversalSheetWorkers#Runequest:_Glorantha_Sheet_Worker" rel="nofollow">https://wiki.roll20.net/UniversalSheetWorkers#Runequest:_Glorantha_Sheet_Worker</a>