i’m honestly not trying to be obstinate. this cha...
# sdf
m
i’m honestly not trying to be obstinate. this channel has a retention that hovers around 2 weeks so it’s absolutely possible there were details included here that are lost to history. but there are only 2 weekly help center updates that reference SDF SDK updates this year: April 15th:
Copy code
SuiteCloud Development Framework
    SDF SDK 2019.1 has been updated. For more information, see:
        SDF SDK 2019.1 is Now Available for Download
        New Deploy Process in the SDF CLI
June 12th:
Copy code
SuiteCloud Development Framework
    SDF SDK 2019.1 has been updated. For more information, see:
        SDF SDK 2019.1 is Now Available for Download
        New SDF CLI Commands to Upload Files or Folders
Both link to the same release notes doc which itself makes no mention of what was changed when unless you go back and correlate the appearance of the bulleted items to the weekly update message. (the ‘order’ isn’t even consistent in the release notes. the Deploy process changes, from April 15th are before’ the upload file changes from June 12th in the notes.) Including a date or even better a minor/patch version would at least allow people to see what things they may be missing. What’s really important in this case though, is that if there are relevant fixes made, it’d be great if they were documented so people struggling with what was obviously a bug have some hope of noticing it’s been fixed. Admittedly, in this case, if i’d been a better citizen, inferred strictly from the statement ‘the sdk has been updated’ that there was a new patch version (you can’t actually see that until you’ve downloaded and extracted the zip as there’s no patch version/dates/_anything_ on the installation page for the SDK) and upgraded, i would have avoided the wasted day. That’s on me and i get it. But if i had, perhaps as @scottvonduhn did, encountered this specific issue before the relevant update was made, i would have no idea that the issue had been resolved without upgrading and retesting. and, at least for me, i wouldn’t think to retest a bug scenario that wasn’t referenced in the release notes. we’d literally be blindly hoping you fixed something and i don’t feel like that’s a great expectation to set for users. “Stay current, if it didn’t work and you upgraded, it’s 100% on you to revalidate the bug still exists.”
a
Understood. I appreciate your constructive feedback. Definitely we should improve our official communication. I'll pass this to the team to evaluate options. Thank you
m
thank you! and i want to say, with 100% sincerity, the fact that y’all are stationed here, listening to our feedback, (even if it doesn’t necessarily result in substantive change immediately) has made me and i suspect many others SO MUCH more confident in building tools and processes that rely on sdf. i know you catch a lot of flak and i don’t want to be perceived as a naysayer. i’m really glad these tools are getting iteration and the progress is really encouraging. we’ll be deploying a ‘code sync’ utility soon, using sdf to extract all custom objects and suitescript files into version control so we can isolate any modifications and it’s going to be a HUGE win for our compliance/controls team. these tools make that possible. so, honestly, thank you.
👍 5
c
If you all use Jira to track your fixes, they have a decent release notes feature built in that can automagically spit out some nice release notes.
c
Thank you for the Feedback!, we will discuss this internally, please continue speaking up that we are listening and will continue improve our tools based on our customers needs.