Re-analyzing the STEP version/updating system

[Proton]

It’s taken me some time looking through patch notes to try to figure out exactly how the process of updating the STEP guide works. As I understand it, the workflow is something like this:

1. Official release of version 1.
2. Incremental changes made over time to version 1, but remaining the same “version.â€
3. Official release of version 2, leaving version 1 stable(?) with the last set of incremental changes it had.
4. Incremental changes made over time to version 2, but remaining the same “version.â€
5. Official release of version 3, leaving version 2 stable(?) with the last set of incremental changes it had.
6. Et cetera.

This seems messy to me. It involves constant revision of patch notes with “post-release†sections, and users not knowing whether anything has actually changed since they installed the most recent version. I feel that a paradigm similar to software code development would be cleaner and easier to track, along the following lines:

1. Official release of version 1. It is modified (“hotfixedâ€) only to amend unforeseen game-breaking issues or unexpected unavailability of a mod. Hotfixes append to the version number in the form of 1a, 1b, 1c, or 1.1, 1.2, 1.3, etc.
2. Incremental changes made over time to “STEP Forward,†an in-development, possibly unstable live branch of version 1 (automatically updated with hotfixes applied to version 1).
3. When stable, STEP Forward is released as version 2. As with version 1, it is only modified with hotfixes. Version 1 is officially unsupported and will no longer receive hotfixes.
4. Incremental changes made over time to STEP Forward (automatically updated with hotfixes applied to version 2).
5. When stable, STEP Forward is released as version 3. As with version 2, it is only modified with hotfixes. Version 2 is officially unsupported and will no longer receive hotfixes.
6. Et cetera.

This paradigm makes it so users have a clear indicator that the version they are running is not the most recent, and also makes patch notes easier to maintain, as they should only ever change upon addition of a hotfix.

 

...I also think “STEP Forward†is the coolest name for a live branch but that’s kind of a personal point.

[DoubleYou]

The problem is that mods update/change without our permission (and should), which is generally the reason for the post-release changes. If it was simply software it would be easy, but we are incorporating a bunch of volatile assets into a collective assembly.

[Proton]

I see—so effectively the intent behind the “hotfix†restriction I described?

 

In that case, I suppose, I still feel it would be ideal if each batch of such post-release changes came under the (small) banner of a hotfix letter, for the same reason mentioned above: it should always be readily apparent if the current guide has changed since a user last followed it.

[TechAngel85]

The "live" Guide is just that. Live. Meaning changes can happen to it at any time. This is because we may have to make updates to keep the Guide current and working. New releases usually only contain new or removed content. Then to keep that content current until the next release, we have to make "live" updates. This is no different than Microsoft or other software providers providing updates with actually changing the version of the software. It's a fairly common. When you update Windows, you will have the same version...just updated because a few bugs or holes needed to be fixed while the next version is being worked on.

[Proton]

All right, but my point of not knowing whether you're out of date or not still stands. If STEP had an automatic updater then being informed of new changes wouldn't be necessary, but currently it requires more than a glance at the main page to find out, and I reckon a glance is all it ought to take.

[z929669]

That's why we have the changelog listing "interim release" changes. People will need to be familiar with their own particular setup to understand whether or not they are in sync with the latest. Most people don't vigilantly monitor the changelog. Furthermore, most people also customize STEP to their own needs. Finally, we also make mistakes that must be corrected ... going live drastically increases the effective testing pool that uncovers those mistakes.

 

It's just a 'guide.' each user constructs it independently, and we have limited ability to test everything outside of our own unique setups. We also don't have the time to optimize for user convenience (branching, versioning, hotfix notifications, alerts, announcements, etc.). At any given time, if one follows the live guide, they should be good to go. We don't commit to resolving all diffs for each of our users, nor do we want to. I would be surprised if more than 5% of our user base has STEP and supporting elements installed exactly as specified in the guide. I would be just as surprised if any two of those 5% had an identical setup.

 

Our current process is as simple to maintain for our staff as possible, and first priority is convenience of the maintainers. Given our limited time, user convenience is necessarily the second priority. Much of our work goes into simplifying maintenance, which is limited due to the instability of the hundreds of independently-maintained dependencies. We often get opinions from people with good ideas, but at the end of the day, the ideas of the people actually committed to ongoing maintenance rule things. There are only 5 of us handling most aspects of the workload (mod testing, guide building, community outreach, infrastructure maintenance). We get invaluable assistance from other staff and the community, but only we 5 have been around consistently long enough to shape the mechanics and maintain consistency.

 

The best way to understand is to become active in mod testing and guide(s) administration. You will quickly see that handling STEP as 'software' is impractical. The STEP guide is really very much like a wiki. Stasis can never be achieved, and volatility rules each moment. It works quite well, actually, given so few are administrating. It would take on the order of 100 full-time employees to administrate STEP to the degree stated in the OP.

 

We encourage anyone to jump in and help out, but we won't adopt any new methods unless they are no-brainers that ease maintenance for us within the current paradigm. On the other hand, we will adopt new ideas/paradigms if the bearer of those ideas is as committed to long-term supporting the project as us 5 ;)

[Proton]

This response satisfies me. Thank you for taking the time to explain :).