11 replies to this topic

[Creepin]

Recently it became some kind of normal to get mods (including BWS) from github "master" release instead of official numbered versions. This is something I perceive as largely harmful for mod users, and since I do believe that modders are not dumb, I had to assume I'm missing something crucial here, and would be grateful if someone will point it out for me.
 
So far, the way I understand the process of creating/updating a mod, you basically add something every day, breaking something, inventing something new, fixing that which you break before while breaking something more, polishing, fixing more, and - tada! - here comes a newly released stable version. With github, no player will have the same version of mod, and this is what I don't understand. So, for example, player who downloaded mod in monday will have a creature A spawn broken, in tuesday - a new item added, in wednesday - creature A spawn fixed while creature B spawn broken along the way, in thursday - new item deemed overpowered and removed, in friday - creature B spawn fixed. Pure hell from my PoV - how am I supposed to know that today is the right day to get a mod? Also totally breaks concept of "finding the thread with your bug reported by previous ten players and finding a solution inside": now my bug will always be mine alone for I will be the only one unlucky enough to download mod in the sunday after 10 am but before 6 pm, with nary hope of finding a thread about it. The lack of publicly announced stable versions makes predicting an optimal moment to get things downloaded impossible, I mean, literally: right now I'm pondering if I should install BWS today, or wait for tomorrow, or wait for the day after that... and what is worse, because of BWS itself became rigged to donwload github "masters" of mods instead of numbered version, no matter on what day I will run it, along its 200 mods downloaded it will drag 10 - 20 mods that are work in progress, half-way to the next stable version with its engine parts disassembled and scattered across the garage in process, instead of mod's previous stable version. How do you deal with it folks?

Edited by Creepin, 23 November 2015 - 01:36 AM.

[Roxanne]

I give my personal point of view (as modder who has recently changed to github and - after some initial hesitation now uses it in a quite active form just like creepin described).

 

1. There are mods and there are mods -

2. Every now and then there are bugs detected in mods that are considered final or the modmaker decides to add a new episode or a ToB sequel etc. Those bugs are intermediately fixed (if you use BWS/BWP) in the fixpack and maybe later included in a release. Your understanding of a product and its release cycle is correct here.

2. There are mods no longer maintained which have bugs known for a long time and where the fixpack solution is an almost permanent one. Currently there is no mechanism for those as long as no one *adopts* those old mods and ventures to do a new release.

3. There are mods designated beta, work in progress etc - They are declared as such and you should not be surprised to find bugs and issues with them. The modder is actively testing and developping and fixing them while those who decided to use the mod provide feedback. This is a very interactive process and you can deal with it in two ways

a. Collect a number of issues/bugs etc, fix them, do a regression to verify that your fixes/additions have not broken something somewhere else - and if confident put out a new release. For a mod in progress those new releases will be quite frequent, ie. depending on the scope of the mod (maybe it has large contents) you will have the situation with players using and reporting on different versions of the mod with duplications on already known or fixed issues etc. On the other hand you will always be able to trace a trouble report exactly to the version that caused it.

b. Use the advantage of a dynamic repository (like github) and commit everything you are confident in to that downloadable version.For a new mod that may gain new interested players daily, the advantage is, that every new download will be the *best* version currently available while for those using a previous version nothing much changes to variation 3a.

c. For a large mod with work in progress (see SRv4, Might and Guile, my own mod, SCSbeta, etc)  *predicting an optimal moment to get things downloaded [is] impossible*. This is the nature of such work. Those mods should adequately inform you about their status and policy - and it is for you to decide if you want the mod under these conditions or not.

4. With respect to my own mod - I followed the method of 3a when I started the public testing. I just recently changed to 3b when I learned to handle github and saw the advantages of this method (for me!!! This is not a global statement!!!). The arguments for my own mod were, that it is such a large mod, that if you start it in a game you will not have come to its end in a significant period (how long does it take you to go through BGT with all the megamods until ToB end??). For my mod I will always face the situation that people in the ToB sequence will most likely have a different version still than those starting anew.

5. My conclusion

- various options to maintain mods are available.

- there is no one-size-fits all

- for work-in-progress the new github method opens for possibilities we did not have before

- each modmaker needs to make an educated decision to see what is best for hisher mod and the status it has.

- the modmaker, if using github, should take care that what he commits to the community, is adequately tested (as far as possible) and in a small scale stable - you do not commit your working version directly to github.

- github updates must be considered as frequent mini-versions and be useable like real releases

- modmakers should publish their used update policy in a way for the user to make a decision whether to use this work-in-progress or rather wait for a finished version - if ever that comes. (It is a contract with the modmaker where you say :I know what you do, I know the shape your mod is in, I agree to take the risk)

- The BWS/BWP support this approach and classify mods accordingly in their recommendations.

 

Edit:

There are also other uses for github in BGT community, like features the BWS uses. It allows multiple contributors to propose corrections/addition/changes to the existing product in a development sideline - when consensus is reached and the proposal ist tested and ready, it is merged into the master and now ready for download.

Edited by Roxanne, 23 November 2015 - 02:55 AM.

[The Imp]

... so as not to derail this topic

...

By the way *this modern github craze* is what the fixpack and BWS guys do (almost) daily - the BWS you download today will most likely be different from yesterday's and Lollorian will have fixed all the issues reported to him until the *commit* was done. Always fresh.

Yeah, but that's a little different, when they know that they are going to do so, so they can make a local copy tries and then set it to be distributed by enables pull request(also, that's two people approving one step)..

3c. Just use the 3b approach and you can avoid the non predictability.
Aka, the BWS should try to use the actual releases, not the alphas for the most mods. Or the BWS should ad an option to use the very latest releases or the like, which uses the masters and not the release links.

[Creepin]

Many thanks for your exhaustive explanation Roxanne!

These bits were especially useful, because I thought that every half-way work in progress was being stored directly within master, and that everyone could change it on its own accord:

- you do not commit your working version directly to github.
- github updates must be considered as frequent mini-versions and be useable like real releases
- when consensus is reached and the proposal ist tested and ready, it is merged into the master and now ready for download.

Guess now I will use modern BWS quite less warily

Edited by Creepin, 23 November 2015 - 03:53 AM.

[agb1]

The fundamental problem with slow releases in the context of modding is what Roxanne noted: the game is huge especially with added mods and it takes a very long time therefore to play through it fully. So it is not practical to fully test a mod after every change by playing through the whole game. This means that a mod author must be focused in their testing and rely on the community to help report bugs (particularly bugs caused by unexpected compatibility problems with other mods the author does not usually play with).

As Roxanne said, some mods are not under active development, so for those mods the only changes are community bug fixes. With Lollorian's BWPFixpack, the very latest fixes are always available for new installations.

To help with the question of "which version do I have?" the BWS now puts an install date in the WeiDU log. I am also investigating how to get the GitHub commit version automatically for each mod to include in the log also. This would make it even easier, but already it is not difficult.

For mods that are under active development, it is a decision for the modder and the players: any updates to a mod that is undergoing changes in design (new features, changes to features) will have fluctuations in quality (remove some bugs, maybe add others). Luckily, the "components" concept makes it possible to localize changes and communicate them to users (easy to say "I changes X component only") so users can make informed decisions about whether they want to take up a mod while it is under development.

With BWS we are categorizing mods and individual components according to their quality (whether they have known problems that require expert fixes or even CLUAConsole workarounds) so players who do not want to analyze too much can rely on the latest version of the BWS tool for guidance about which mods are "safest" to use (as far as the community knows). This is an ongoing process but the direction is towards greater stability and higher quality so any time you start a new install it should be at least as good as the previous one.

[Argent77]

Recently it became some kind of normal to get mods (including BWS) from github "master" release instead of official numbered versions. This is something I perceive as largely harmful for mod users, and since I do believe that modders are not dumb, I had to assume I'm missing something crucial here, and would be grateful if someone will point it out for me.

That depends on the GitHub setup modders are creating for their projects. Git uses something called "branches" that allows you to continuously update your mod, but at the same time ensures that users can only download a fixed release at any given time. For my projects I'm usually using a "master" branch for official releases and a "devel" branch that I'm using to continuously update stuff. The master branch acts as a "snapshot" of a specific state of the mod, which doesn't change until I'm creating a new "snapshot" by merging the master branch with the devel branch at a given time. That way you can easily simulate the traditional system of fixed release versions.
Since branches are easy to create and manage, modders could create separate branches for experimental stuff and decide later whether to merge them into the official branch or discard the whole branch.

I would strongly recommend every modder to use a master/devel setup or something similar. That way you can publish releases in a controlled manner and it is easier to manage as to keep all commits locally until you decide to publish a new release.

 

[agb1]

In another thread recently I have been suggesting definitions of "Expert" mods and components as mods and components with known problems.

I also have a suggestion in that thread to replace the term "Standard" mods with "Stable" mods, meaning "no known problems." We also have "Tactical" for "no known problems, with increased difficulty."

The definition of the "Recommended" category is less clear, because it includes a judgment about whether a particular mod is "appropriate" for new players (i.e., the "Recommended" category is like the community's advertisement for the BiG World Project, a set of mods that give an "enhanced" experience of the game with minimal problems).

Do we need additional categories?

[waebbl]

To help with the question of "which version do I have?" the BWS now puts an install date in the WeiDU log. I am also investigating how to get the GitHub commit version automatically for each mod to include in the log also. This would make it even easier, but already it is not difficult.

 
https://developer.gi....com/libraries/ might help you with this. Althought there's no AutoIt3 API available, they have a JavaScript API (node.js), which is IMO usable from within AutoIt, where you can get an array of commits, for example, as well as other nifty information about a repository hosted at github.
 

I would strongly recommend every modder to use a master/devel setup or something similar. That way you can publish releases in a controlled manner and it is easier to manage as to keep all commits locally until you decide to publish a new release.

 

I fully agree to this, the branch concept with git is a very powerful feature! Even if your changes are commited only locally in the first place, and only get updated on github, if you push them.

If you introduce bigger changes to your mod, you're better bet if you develop them within a new branch. You can easily switch between different branches, i.e. to fix simple bugs on your master branch and publish them, without disturbing your current progress in other branches. This way, you keep your master or release branch clean from any development related errors. Once you're happy with your new development, you merge the branch back into the master branch for your next release.

Edited by waebbl, 23 November 2015 - 05:56 AM.

[Lollorian]

I have nothing to contribute to this topic yet but wanted to point out:

 

To help with the question of "which version do I have?" the BWS now puts an install date in the WeiDU log. I am also investigating how to get the GitHub commit version automatically for each mod to include in the log also. This would make it even easier, but already it is not difficult.

This was ABSOLUTELY not meant to answer "which version do I have" - you could have a really old BWS version (probably from a third-party source) and install shitloads of old mods and still have the installation date show up as today.

 

Mod versions should be the responsibility of the mods themselves, not the BWS - if the commit metadata pulling thing can be implemented that's a plus - but seriously mods without proper versioning should be chased by pitchforks

[agb1]

To help with the question of "which version do I have?" the BWS now puts an install date in the WeiDU log. I am also investigating how to get the GitHub commit version automatically for each mod to include in the log also. This would make it even easier, but already it is not difficult.

This was ABSOLUTELY not meant to answer "which version do I have" - you could have a really old BWS version (probably from a third-party source) and install shitloads of old mods and still have the installation date show up as today.

That's a very, very good point.

 

Mod versions should be the responsibility of the mods themselves, not the BWS - if the commit metadata pulling thing can be implemented that's a plus - but seriously mods without proper versioning should be chased by pitchforks

Perhaps we should adopt versioning for BWS too... :shifty-eyes:

[Lollorian]

Btw, just so people understand where Creepin is coming from - I think the entire BG1UB master branch fiasco is to blame to his/her paranoia (I may be wrong)

 

Like I mentioned in the other thread, devel-master is the way to go if people are not intent on pushing out releases.

 

@agb1: Nah the BWS don't need no version because it's a special snowflake (but in all seriousness, yes versions would be preferable - the BWPFixpack has a pseudo-versioning system in its BWP Fixes.txt and the lolfixer has a DDMMYYYY version of the last change made in its VERSION tag so...)

 

The DDMMYYYY seen beside the BWS.tp2 (not the installation date) is a very nice candidate for versioning

Edited by Lollorian, 23 November 2015 - 08:01 AM.

[Argent77]

And for those who don't wan't to deal with branches, we have also special link for "newest release of the mod from Releases tab": for example
 

lynxlynx.info/ie/modhub.php?AstroBryGuy/bg1ub

Nice! Didn't know that one yet. But it requires the GitHub project to have at least one official release in the "Releases" tab. Not all mods provide one.