the argument - which has still not been acknowledged - that the alternative is "unless you are this specific pack I know keeps up to date, don't bother with support, I do not care".
...
Then I am going to just tell packs they are ineligible for tech support. Do you want that?
Of course not.
...
What exactly is it you want? Because it is starting to sound like people are demanding - but not willing to openly say - they want both tech support and the ability to host old versions as long as they please.
I agree with you. Saying that old packs can get no warnings, no notice, no nothing, and still expect people to report problems, is crazy.
Lets put this into perspective:
1. I had a world destroying problem with forge. I was not on latest (No, I don't update forge three times a day when it updates rapidly in a weekend, I wait for it be stable for a bit. No, I don't update to versions that people report introduce bugs, see the biome issue from ... 1224 to 1230?). I reported it. I got banned from the forge forums as a result.
2. I regularly report problems -- SERIOUS problems -- with Mac OS 10.9.5 to Apple, even though the current version is 10.10.3. I'd love to see these fixed, because Apple does still release patches for 10.9.5. But, they only fix 10.10, and tell me to retest with the newest OS.
Never mind that this breaks several programs that I use, or that a time machine backup, once 10.10 has been seen/backed up, will refuse to restore 10.9. Or at least, I think that's how it works -- I know that when I tested 10.9 on my 10.7 machine, found it had serious problems, and tried to go back to my TM backup, that it refused. I had to redownload 10.7 from the internet, and then restore my system/personal data after the software was back. That was slightly less than 100%, and it took me a while to track down and reinstall the (few, but not zero) programs that did not restore properly.
(BTW, the current issue I've reported is that time machine has failed to backup some major files for me. So ... guess what I do *NOT* want to do?
(And yes, when my machine was partitioned/formatted, I made sure to set aside enough room to have a second copy of the OS on a second partition, so I could do test installs. But if I can't rely on time machine to rescue me if time machine is what is having the problems, it becomes worthless.)
3. Imagine the idea of saying "First go to the modpack creator for support, then go to me". If you wanted people to have customized modpacks, this might be the approach. But in truth, people won't -- they will go directly to you.
There is no functional difference to you between "This is a customized, pack-specific behavior", and "This is a year-and-a-half old monster pack".
You have found that people don't go to the FTB monster people, they go to you. Ditto for custom packs.
I do not blame or disagree with you at all for the "Packs must use stock formats; personalized system can use customizations". If anything, I'd like to see single-player server setups permit customization.
I do not know if this has always been the case, but MT is server side controlled, and RFTools configs being overridden by the client sounds like a bug for most configs.
My memory: MT used to have some things that were not resettable; so, if I loaded up one world, and then tried to load up a second world, some things in the first world would persist. And, this affected server configs differently than single user.
I have not played with minetweaker since ... almost a year ago now? Before Jampack 1; I planned to use it in JP1, but never got to that point of pack development.
The issue with RFTools was fixed; the whole "client and server had to be synched" was causing too many problems, so it had to be addressed.
Maybe, but you are the minority and are not who I have in mind when designing policies. Also, doing so both makes you totally ineligible for support anyways and means you are more competent than the majority.
To clarify: That was a hypothetical based on "what if I ran true single player". Since I do want to play with friends, even if I'm the only one doing RoC, I can't.
Question: Of the two options, which is preferable?
- The update checker as currently agreed to: the closeable popup that can be disabled until the next major version with a command, which will have a config to make it so that only the pack maker can see it, until the pack is determined to have been abandoned (or at least has ceased being updated)
- Modpacks get no support at all. Period. End of story.
I was surprised to see so much "2" support here.
I do like the idea of "Notify OPs, but not normal players".
I do think that "Put a big notice at the start of the report saying Out-Of-Date mod, do not expect a fix without updating" would help, but we've also seen it won't stop the reports.
But the issue is this: People do run old versions. People do want support. Requiring people to update to the latest, and retest, before being able to even _REPORT_ a bug?
I don't mind -- seriously, I expect this now -- being told "Yep, we found that bug, it's fixed in the updated version". (NB: Just imagine trying to transfer stuff from a 10.7 time machine backup to a 10.9 new machine, only to run into a bug that was discovered during 10.9 beta testing, was fixed in 10.9, but affected any earlier backup -- and Apple saying "We won't release a critical bug that prevents you from transferring data from your old systems". Not a joke. Took me over a week, and several attempts, to fix. Had I known it would be that long, I would have gotten their customer service people to send me a firewire adaptor for this new computer, and pointed them to that technician's report as justification -- firewire (direct drive mode) did not have the flaw that time machine transfers did.)
I would love to see people actually maintain good branching behavior, and have a bugfix branch, release branch, etc.
But the reality? GIT is probably the first SCCS that does this behavior properly, the setup needed to handle this is the exact opposite of the "introduction to GIT" chapter one tutorial of almost every book on git (every book/tutuorial I've seen, anyways; I'm not the only one that has made this observation), and the GIT branching system is as powerful and undisciplined as "goto", if not "calculated goto". (Actually, from what I've seen of some of the plumbing, probably calculated goto).
Given the lack of a tutorial on a proper branching model that accurately supports a vendor code base, the local code base, the various releases, hotfixing the releases and pushing the hotfixes to both the maintenance and the new development, etc. -- I'm not surprised that it isn't yet widely done.