SVN and Changelog support (moved from BatBrain thread)

[josmul123]

Can we PLEASE get a code repository for this? And WHAM too? I have a script that auto-updates all of bumcheek's scripts, and it's proven to be a million times easier than logging into the forums to download every time there's a new update (and the updates have been extremely often lately).

It just seems like every day I start up bumcheekascend.ash and it's whining at me about updates to WHAM and BatBrain. I *REALLY* appreciate that you guys are on these scripts and keeping them going. I just think updates could be easier.

EDIT: I love you Winterbay. I hadn't yet gotten to the WHAM page for updating this time around. ;-)

 

[Theraze]

Funny that you mention WHAM, when it's had the SVN setup since 6/5...

 

[Bale]

I believe that zarqon is waiting until svn updating is part of KoLmafia's point release so that all of mafia's users have access to it, not just the people who are willing to download daily builds.

 

[josmul123]

Funny that you mention WHAM, when it's had the SVN setup since 6/5...

Funny that I edited my message two minutes before you replied. ;-)

 

[Theraze]

Well, before I hit the post button after validating the date. The part before that had been written quite a bit before...

 

[zarqon]

I believe that zarqon is waiting until svn updating is part of KoLmafia's point release so that all of mafia's users have access to it

This. And: I'm also waiting until I understand how in the heck it works. From what I understand so far, there's a notable downside: users can now conveniently update without reading release notes. I prefer my users to look before they leap, not only for their own benefit but also to give myself some insurance -- they can't complain about the script "not working like it used to" when changes are clearly outlined right at the place they downloaded it from.

It's also a bit cathartic knowing that at least a few people are reading about (and possibly even appreciating) all the effort I put into maintaining and improving my scripts. SVN may take that away from me.

Basically, I don't want people to be able to blindly update my scripts. I want them to at least have to choose to ignore the release notes. I want user accountability. So I need to find an update solution that I'm comfortable with.

 

[lostcalpolydude]

It's also a bit cathartic knowing that at least a few people are reading about (and possibly even appreciating) all the effort I put into maintaining and improving my scripts. SVN may take that away from me.

Basically, I don't want people to be able to blindly update my scripts. I want them to at least have to choose to ignore the release notes. I want user accountability. So I need to find an update solution that I'm comfortable with.

I expect that if I used WHAM and BatBrain, I would wait several days between updating. I could easily see missing a few release notes posts without trying to not read them (if I wasn't reading every post on this forum to begin with). With SVN updating available in mafia, I could see a lack of SVN availability as a reason to not use a script that needs frequent updating. I have always considered the process of visiting a forum thread just to download an update to be an unavoidable nuisance, and now roippi has made it avoidable.

I don't actually use BatBrain though (already covered elsewhere), so maybe my opinion is irrelevant to you.

 

[Bale]

Basically, I don't want people to be able to blindly update my scripts. I want them to at least have to choose to ignore the release notes. I want user accountability. So I need to find an update solution that I'm comfortable with.

This sounds like a feature request. You wish to be able to require that users updating your script through svn need to read the changelog. That seems quite viable. I suppose Roippi would solve that by having a file at the root directory of the svn repository that informs mafia of this desire as dependencies.txt informs it of prerequisite scripts. He might also want to have a user preference to always read changelog before updating, only read if scripter requests it, or never read changelog even if scripter requests you read their changelog. I'm not sure how you would feel about user being able to choose ignorance from preferences, but if you don't like that please say so in the feature request.

I'd suggest you make the feature request. Right now while mafia's SVN is taking shape is the time to guide that shape. Roippi has been very responsive to our needs so I hope he'll accommodate yours as well.

 

[Veracity]

Basically, I don't want people to be able to blindly update my scripts. I want them to at least have to choose to ignore the release notes. I want user accountability. So I need to find an update solution that I'm comfortable with.

You wrote zlib. This is a library for the use of other scripts. I will never use it in a script that I write, but the handful of scripts I use that other people wrote - CounterChecker, Bale's OCD, autoBasement - all use it.

If you put zlib under SVN and the others mark it as a dependency, if you update zlib, it will autoupdate for me.

But, if I understand you correctly, you don't want that to happen. You want to require that I read the release notes for zlib. Am I correct in that understanding?

Similarly, BatBrain is a library to be used by consult scripts. The single actively supported public script using it is WHAM. You put BatBrain under SVN, if I use WHAM and you update zlib, I will get the BatBrain update. But, you don't want that to happen. You want to require me to read the BatBrain release notes, even though I have absolutely no clue about how it works; all that matters to me is that the script I use that calls it uses it correctly. Am I correct in my understanding?

So, when you say "you want your users to look before they leap", it seems to me that your "users" are Bale and Winterbay, whose scripts call your scripts, not me, or the hundreds of others who do not use your scripts directly, but use scripts that use your scripts.

With SVN updating available in mafia, I could see a lack of SVN availability as a reason to not use a script that needs frequent updating. I have always considered the process of visiting a forum thread just to download an update to be an unavoidable nuisance, and now roippi has made it avoidable.

Exactly this. I downloaded zlib and Bale's OCD a long time ago and, once I got them working, have ignored subsequent calls to update. In fact, for my multis that use CounterChecker, I commented out the "update available" checking, since I was happy with how it worked and didn't care if there were updates available.

 

[zarqon]

You want to require that I read the release notes for zlib. Am I correct in that understanding?

No. I want the release notes to be accessible when you update. I want to require that you deliberately ignore the notes, or a link to them. I want to allow people who are interested in what's changed to easily access that information when they update rather than needing to track it down themselves.

My desire is for release notes (either opt-in or opt-out) to be a part of the update process, whether through a KoLmafia feature or through ZLib. Release notes are a community-builder and a point of relation between authors and users. I and authors like me could keep these scripts to ourselves, but we don't, because we care about the community aspect of scripting. Things like idea-bouncing, receiving useful criticism, and even engaging in some friendly banter. Release notes are an important touchpoint for these aspects.

I fully intend to use SVN. It's lovely. But I need to find a way to incorporate release notes availability into it, that's all. When I as a user update something I want to know what I'm getting, and I want this information to be available to my users, whether they choose to view it or not. This is doable with things the way they are now -- it's simply a matter of finding the best way. Shall ZLib's SVN-friendly check_version() break for users still publishing scripts in forum posts, thus aggressively encouraging everyone to make the switch? Shall there be multiple forms of check_version()? How shall check_version() react if it detects the script has been automatically updated on login? These are things I need to think about. It doesn't mean I'm going to do something childish like refuse to use SVN just because people don't care about my release notes; it's just a hurdle to clear before I'm able to transition. I have to think about more than just my own scripts here, and if new update-related functionality is going in ZLib it should be something fairly stable, so it's taking me longer to make the transition.

 

[roippi]

Well, my thoughts, in some sort of order:

- it's your software and you can do what you want with it. Personally I think your desire to confront end-users with update notes is unreasonable. I use that word in the sense that basically no other software in the world works like that. At best a CHANGELOG.txt will be provided, but more frequently an executive summary exists somewhere on a web page, if at all. The majority of end users simply don't care - and those advanced users who do will seek out the information themselves.

Basically, I don't think you are going to lose a single reader-of-release-notes by moving to svn. The scripters who were reading them before will continue to read them, and the lay users who only updated because their script was nagging them will continue to not read them.

- Open source (unlicensed) software means that eventually someone is just going to plop your scripts into their own svn repository and have their script declare those as dependencies. Out of respect for you, I think that people will generally eschew this line of action except as a last resort, but it theoretically would/will happen given enough time. I really don't mean this as an ultimatum or a threat, though it kind of reads like that, sorry.

- I -love- reading your release notes, I think they are genuine works of literature.

- I consider the svn code stable now. I will not be making any more changes to core functionality outside of bugfixes. And I think most of the bugs are squashed by now.

- I'm open to including some native functionality for providing version comments. The most likely solution is an opt-in ability to display new commit messages when updating.

- Last philosophical point. The whole point of this svn system is to break down the barriers between scripters and users. The antiquated system of search-download-move is an enormous demotivator for many users. I sympathize with that. So the feature that you feel is good for community-building is in my eyes very, very bad for the scripting community.

 

[zarqon]

I think we all agree a lot more than it seems. Let me say some things that it seems I'm being interpreted to say the opposite of.

• I love the new SVN system and find it a vast improvement on the forum post method, both for authors and users. This is a massive step forward in script distribution and upgrading.
• I'm thrilled with the dependencies functionality and very much looking forward to people's scripts breaking less and working more easily.
• I'm not holding out -- I'm working on transitioning.

Now, I should have said all that first I guess. I haven't disagreed with a single thing anyone has said, although I have found a some wordings unexpectedly confrontational, as though we're arguing about something.

So let me make sure I understand this before I somehow make anyone else take unnecessary umbrage. When a script updates, how do I know? I assume there's a readout in the CLI. And then if I wanted to see the release notes for a particular update, would I have to find that script's thread in the forum, and then navigate to wherever the updates were described to read them? This is what I view as a needless inconvenience to work around -- a significant separation between updates and notes. As we've finally successfully avoided the previously "unavoidable nuisance" of clicking to a forum and downloading an attachment to upgrade a script, I'd like to not throw out the baby (nearby, handy release notes) with the dirty bathwater (lots of clicks and delay to update).

I'm thinking it should be possible at script runtime to detect whether a script was updated since its last run, then provide a "ThisScript has updated to version 1.23! Click here to see what's changed." link to the changelog in the CLI. This is really all I'm asking for. If that's somehow a confrontational request, I don't know what to say.

 

[lostcalpolydude]

https://sourceforge.net/p/kolmafia/code/HEAD/log/ is a decent URL for people wanting to view changes in mafia, and a similar URL exists for any sourceforge project. I don't know where the best place is to put that, but any person that has mafia updating when they log in is probably going to miss it in all the CLI output.

 

[Crowther]

I'm not sure I'd notice a script update in the CLI and that could be a problem. I think I'd like to see a popup with the release notes when a script is updated and maybe an option to never show them again for people who don't care. And I normally hate popping windows.

 

[Alhifar]

Honestly, as an end user, I really don't care about what exactly has changed in, for instance, BatBrain. I'm sure Winterbay, on the other hand, does. I feel like whether you pop up the release notes or not, the same people who actually read them before will STILL be the same people who read them with the current svn solution.

 

[zarqon]

I also dislike popping windows. I don't think that's necessary, although if it were an option I'd enable it. I also don't want anything that stops automation, like an alert box or somesuch. I just want people to note that their script has updated and be able to easily access the release notes for it. People often have pet issues and wonder whether they were addressed with a given update.

I think printing a message (with changelog link) when the script is run would be the best solution for me to swiftly implement in ZLib, since as lost points out CLI messages during login tend to get buried. If they don't want to click the link, that's fine, but the important part is that the choice is given to them. That can be accomplished in-script if there is a way to detect that the script has updated since its last run. Which there may already be -- I haven't investigated.

ETA: @Alhifar: Thanks for keeping the thread on topic by mentioning BatBrain.

 

[lostcalpolydude]

Which there may already be -- I haven't investigated.

I think that would require the script to set a property indicating its current version for comparison. I don't know if there's a good way for a script to know what version it is, other than continuing the existing system of having an in-script setting for what version it is, though that seems like it should be unnecessary with svn versioning. Maybe another ASH function could be added to access that value.

 

[fronobulax]

And then if I wanted to see the release notes for a particular update, would I have to find that script's thread in the forum, and then navigate to wherever the updates were described to read them?

You say that like it is a problem but it is exactly what I do now except, perhaps I start the process by clicking on a link in the gCLI.

I also have to wonder what is wrong with just declaring ZLib_ReleaseNotes.txt as a data file that is under version control? Users are told ZLib is getting updated and the ones who want to know what changed can just look at that file in the data directory.

 

[Bale]

I like fronobulax's idea about adding release notes as a data file and it looks like roippi is already adding the option to svn update:

> svn update

Updating all SVN projects...
bale-relay-woods_getstuff is at HEAD (r5)
Validating repo...
Repo validated.
Updating bumcheekascend-bumcheekascend...
C:\Users\Ben\workspace\kolmafia\svn\bumcheekascend-bumcheekascend
U http://svn.code.sf.net/p/bumcheekascend/code/bumcheekascend/scripts/bumcheekascend.ash
http://svn.code.sf.net/p/bumcheekascend/code/bumcheekascend/scripts
http://svn.code.sf.net/p/bumcheekascend/code/bumcheekascend
At revision 284
Pushing local updates...
bumcheekascend.ash => C:\Users\Ben\workspace\kolmafia\scripts\bumcheekascend.ash
Done.
Update info for bumcheekascend-bumcheekascend:
------
Commit info for r284:
Author: winterbay2

Remove partial removal of workaround for the KoL shop revamp
------
Requests complete.

 

[Chef_Rannos]

It's also a bit cathartic knowing that at least a few people are reading about (and possibly even appreciating) all the effort I put into maintaining and improving my scripts. SVN may take that away from me.

Basically, I don't want people to be able to blindly update my scripts. I want them to at least have to choose to ignore the release notes. I want user accountability. So I need to find an update solution that I'm comfortable with.

This is why I subscribe to the threads of scripts I use. I may not have time to look through the forums much, but at least I can see the posts in my email when I get a chance.