#Spring Cleaning

1 messages · Page 1 of 1 (latest)

devout barn
dense prism
#

Does this include WFRP premium modules? I am still in the middle of updating V9 Journals to V10

#

They still work in v10 and v11

halcyon frigate
modern belfry
#

If a mod still works, it shouldn't be archived imo, regardless of what it's compatible with.

delicate turret
#

Any chance to have a state different for each fvtt major version contacting the package list in the future? One thing often said is: you don't need to update. But if you want to keep playing this old unmaintained system you can't because it is not listed anymore. Like, maybe each major version could only show packages up to two older majors

devout barn
feral jacinth
#

cannot be installed within Foundry VTT

  1. does this also apply in V9 Foundry installations?
  2. does this apply to packages installed directly from manifest link?
devout barn
west karma
modern belfry
#

Why should we have to update it if it still works?

halcyon frigate
devout barn
west karma
halcyon frigate
#

So to make my old module for V9 be unarchived I need to do a stupid update like change a letter?

sand sphinx
#

All you have to do is to mark it as compatible in the admin page, the manifest doesn't even need to be touched if it works as is

devout barn
delicate turret
#

But it has to be compatible, you can't still show it for your v9 users

halcyon frigate
devout barn
#

There's no way for us to know if your package still works if it hasn't been set as compatible.

This isn't a new process.

delicate turret
#

Also it hides modules and systems from people who left the community but could still be played on older versions

feral jacinth
#

"set as compatible" = set the VERIFIED CORE VERSION field to 10 (or higher), to be clear

halcyon frigate
devout barn
#

Regarding v9 compatibility---users can install it directly via manifest or if there's some sort of special circumstance i can unarchive them by name- but v9 closed when we released v10--and we're now in v11.

brisk river
#

I think showing versions that work for older versions on older versions makes sense, but it's a technical change that is outside the scope of this thread and is probably better raised as an issue/suggestion instead

halcyon frigate
#

Also, a great addition would be (if it is not already), show near package name (inactive)

#

As I do not know what got deactivated if anything xD

devout barn
devout barn
delicate turret
#

This is understandable, but I was asking if it was a thing to be considered for future versions

brisk river
delicate turret
#

I feel like we'll have more and more perfectly playable version on unmaintained package what will be lost to the community

halcyon frigate
modern belfry
#

It was stated at some point that you never had to update your Foundry version if you didn't want to... but now if you don't, you're being locked out of using the built in installer if you like your older version and need it for older version compatible modules.

devout barn
feral jacinth
brisk river
halcyon frigate
stuck robin
# devout barn as i understand it, it would require us to issue an update for v9, v8, v7, v6 to...

Not going back and issuing updates for older versions of FVTT makes sense to me.

But why not go the other way around? Why not update V11 to hide modules that are not verified for at least V10.

That way, non-tech savvy users who want to stay on V9 aren't "punished" for not updating, but you still get this "spring cleaning" effect where outdated modules don't take up space in the built-in installer.

devout barn
# stuck robin Not going back and issuing updates for older versions of FVTT makes sense to me....

I'm sorry to say my answer here will admittedly not be very helpful- but ultimately it's "because that's the way it went."

Initially, we used to delete modules from the repository listing once they reached an outdated version with no maintenance, but that became untenable. The concession on our part was to establish an archived status that would achieve the effect of not bloating the addon list unnecessarily, but would keep the packages as ones devs could administrate.

#

That may change in the future, but it isn't likely to change right now, and this is the process we've used on the last 3 version updates.

brisk river
# stuck robin Not going back and issuing updates for older versions of FVTT makes sense to me....

Doing it like you describe would require sending the data for all of the packages to the local server to filter and display, and the wasted data grows with each version

The ideal situation might be to have the local server include a major version argument in its package query and the backend server return a filtered list, but that would require handling for that on both codebases and clearly isn't an option in the near-term

stuck robin
#

Ah that's true, I didn't consider that.

brisk river
#

Yeah. Loading the package list for 2k modules takes long enough as-is, we don't need even more data to send, lol

west karma
#

It's the sort of thing one forgets is a limit when developing locally. Accessing localhost is more or less only limited to your CPU and RAM speed, something on the order of 10s to several 100s of GB/s, having to hit any networking hardware, even Gigabit Ethernet at ~100 MB/s, is really slow in comparison.

halcyon frigate
#

Like most web apps do these days

#

(Something like algolia/self hosted alternative)

west karma
#

Yea, but that would limit populating all the bits of data in the UI.

halcyon frigate
#

Even now waiting for the package list is uhhh

west karma
#

There is no easy win here.

halcyon frigate
#

But it's discussion for another place

brisk river
west karma
#

Side effect of sending everything means that Foundry can make searches really fast locally with no delay and no additional server side cost.

devout barn
west karma
#

It's not as simple as "flip a switch" as one might think, but it's something to tack to the todo board.

halcyon frigate
#

True

west karma
#

This is something I'm personally interested in for a work project, I've done the work to examine it, Foundry is in the envious position of just needing to rewrite only two programs to use that sort of thing. I think we have like 20, only 5 of which we have source code access.

halcyon frigate
#

I just worked a lot with wokflows like that (search through giant databases from webapp) and my brain is just wired to say "use an index"

west karma
#

Full text search is a bitch.

#

Indexes are good for short strings, not the mountain you get in the descriptions.

halcyon frigate
#

Well you just install elasticsearch... xD /jk of course

halcyon frigate
#

But I also now that it's not easy so I understand that it may never be done/may cost too much to run

west karma
#

Yea, more spent on servers means less to spend on other things, like creating new content and hiring more staff to make more improvements to Foundry. Everything has a cost, just a matter of it being worth it.

summer saddle
#

Something to keep in mind for those who feel it's a hassle to update the compatible version number even it it still works: This helps users understand whether or not they can or should use a module, know if it's still supported, etc.

I've seen conversations about so many modules that seem to work fine, but their compatibility versions are as old as 9 or even 0.8. It's unknown if the developer will still support it or if it's reliable.

In general, it just helps existing users who are wondering if its safe to update their Foundry instance despite the warnings or for new users to know which modules they can reliably use without risk of issues cropping up at inopportune moments.

brisk river
#

It's also a pretty quick thing to do if you have no changes to make. You don't need to cut a new release, you can just edit the verified number in the admin interface and save and you're done. Foundry's manifest handling can use that just fine

#

I think it took me about half an hour or an hour to handle the "V11 update" for four modules. I just loaded a V11 world, poked them for a few min each, updated the verified field in the admin page, and I was done

west karma
halcyon frigate
brisk river
halcyon frigate
#

Also new foundry versions complain if you have non-existing file in manifest

#

Which older ones ignored (complaining about that is a good thing)

sterile spoke
#

I feel like this is going to cause some issues for people that are still running v9 campaigns, myself included, specifically that some of us do change mods a bit. And v10 released less than a year ago in stable.

devout barn
#

We've always archived when a package was more than one version behind.

vital kernel
#

It's it an idea to add a checkbox to the module installation page to display archived modules/systems? This won't help people on v9, but at least it'll help prevent issues whenever v13 is released and v11 modules get archived, or when v9 modules still work on v11.

west karma
#

There is a whole section of the site for archived pacakges.

vital kernel
#

Sure, but having the option to install them within Foundry would be nice, without having to use the manifest url

summer saddle
#

Come to think of it, I wonder if there needs to be a distinction between archived and retired, where retired means, "Don't use this, it's broken and the developer is no longer supporting it."

brisk river
devout barn
#

To some degree while we continue to allow older versions of the software to be installed we make no promises for continued support for those versions. Once a version is older there is some level of acceptability for hoops a user may need to jump through to get those things working.

west karma
#

Nath already said they are not going to make updates for v9 and older to support changes.

devout barn
#

If a user shows up in #troubleshooting on v 7, 8, or now 9 there's a fair to middlin' chance troubleshooters are just going to recommend updating to the new and shiny.

#

We likewise don't expect the development community to keep maintaining their packages for old versions in perpetuity.

west karma
#

The fact we even get patches to the last stable version is a great boon that many other software places don't do, unless you get into enterprise scale software which there are support contracts for.

devout barn
summer saddle
#

Right, I mean if a developer has purposefully archived a module to discourage users from using it. I did that with two modules myself. One was integrated into the system. The other just doesn't work anymore because it imported content from a character builder tool and the data models grew to be too different to be able to reconcile.

halcyon frigate
#

Thanks

devout barn
summer saddle
#

Works for me

devout barn
#

we've done that for some significantly broken packages in the past

#

if you need that done i'm only a DM or a support email away

brisk river
devout barn
#

that also works

#

i just like deleting stuff out of the package list because nexus mods is an atrocity and i don't want us to be the next nexus mods

#

XD

delicate turret
#

I always thought the package listing was a single query to a main server

brisk river
delicate turret
#

I don't know the code, I can only assume how things are coded, which is a bad thing for me to say but I'll say it nonetheless (...Bonk ) but it may be a trivial thing to add. At least on the local server it would be. On the django side, if they have a database they query, it would depend if they have access to the compatibily field directly in the table but if yes, it would also be a quick win

pliant oar
#

The tricky part is to make it useful, older versions of Foundry like v9 would need a patch to take advantage of it

brisk river
delicate turret
#

I don't really mind about that tbh, a quick fix for better handling of archives v11+ would be a huge comforting thought for me.
It didn't occur to me in the previous releases that we could quickly reach a moment where some obscur or simple systems are just "done", and won't ever need to be updated to be fully playable. For those, keeping systems compatible will become only a chore for their developers, and they may drop support because "it just works in vX". They may leave the community, or not just not want to update their systems for newer versions.

One huge benefit I see in the selfhost approach from Foundry is the control you have over your updates. If Foundry VTT now says "we didn't say we would keep support for the package listing", it is a real concern for me that immediately sound like a future abandonware scene with local hacks to change the Foundry API URL to some community custom listing to keep older versions working, etc. That does not sound like something I'd like to see happen to Foundry

#

I'ml certainly not asking to put a lot of works right now for v9, I fully agree that we knew it would happen

brisk river
#

Yeah, I do agree in general. It's ultimately up to staff how they handle it, but I would certainly like to see the ability to continue to install and use unmaintained stuff on older versions of Foundry (especially systems and such) in the long run like that

devout barn
#

For those, keeping systems compatible will become only a chore for their developers, and they may drop support because "it just works in vX". They may leave the community, or not just not want to update their systems for newer versions.
This is something we have been aware of for some time and, while sad when it happens---is a reality.

There will never be a case where we stop developing the API because that way lies stagnation, and systems will either have to update for the new version or become unsupported.

nocturne compass
#

Archiving 'old' packages is a thing that has been happening for ages, this isn't something new even if it feels like it because of the length of time between v10 and v11

delicate turret
#

I don't see how it relate to my message, Nath, I agree with that 🤔

brisk river
nocturne compass
#

I'm responding to:

If Foundry VTT now says "we didn't say we would keep support for the package listing", it is a real concern for me that immediately sound like a future abandonware scene

delicate turret
nocturne compass
#

I think v8 is when we first started archiving old packages.

#

I think. Nath'll know for sure

devout barn
#

v8 was when the community convinced me to stop deleting packages for no-longer-supported versions XD

delicate turret
#

And saying "we always did it like that" is not a good argument for doing things in general :p
It is however a good argument to say "we won't change what is already done", which once again, I agree

devout barn
#

As i said earlier there's probably room to grow with how we handle package listing detailing---but that's not the point of this thread and nothing will really get decided about it in here because i'm neither a dev nor the person who'd make the call on it.

#

i'm not saying we'll never change or that 'this is how we've done it' is justification for how it'll continue into the future---but it's how we'll continue for this version because anything else would likely be a drastic change we can't implement during stable.

brisk river
#

To the issue tracker!

delicate turret
#

Then we are saying the same thing haha, I was talking about that here because it felt the right place (I didn't see a specific topic for this thread so package listing talk felt on topic)
I don't like to create tickets for suggestions before testing the water when it is possible, because maybe it is against Foundry vision or maybe it is already planned

#

It seems like you are not against the idea so i'll do that

nocturne compass
#

And I'm making sure people know this isn't something brand new devised to torment devs. We've tortured devs forever 😉

delicate turret
#

Lucky for me I didn't feel tortured at all but I think my messages were caught in the distress calls from some other devs

devout barn
#

i've developed a bad habit lately of saying what others are saying, but in a way that makes it seem like i'm disagreeing when really i'm just trying to reinforce what they've already said

#

sorry JDW. XD

delicate turret
#

No worries, I feel like most people in your position would already be hiding in a bunker with landmines all other their communication channels so I really don't mind having to explain myself for the chance to be heard, it is way better than we could expect

delicate turret
feral jacinth
#

I think Foundry is already avoiding the "abandonware" issue well enough, because archived modules still have a foundry page and can still be installed through manifest links (which are even available directly in their pages). I'm okay with discoverability and search being lost, if it's for less than one percent of users, and those are almost all users who already have their compatible packages installed and aren't looking for more

#

I'd like to have the range increase a bit, though - rather than archive everything from 2 versions ago, make it 3 or 4 versions ago. as we go forward, Foundry is expected to make less breaking changes and become more stable over time, which also means package developers should expect to make a less active effort maintaining their modules. there's always going to be some small percent of modules being "abandoned" every year, but abandoned modules aren't broken modules, and might be perfectly functional, yet have a single developer who got hit by a bus and won't update the admin site anymore

#

the biggest frustration I imagine for old users (e.g. v9 users) is that they might want to copy over their list of modules to a new installation, and find themselves having to find and copy every single module's manifest url, rather than "only" having to search every module's name in the setup screen. this can be resolved by adding a setup screen import/export feature for module lists, which is something certain power users would already like to have, e.g. when moving to another hosting computer

brisk river
# feral jacinth I'd like to have the range increase a bit, though - rather than archive everythi...

The hit-by-a-bus isn't really an issue regarding transferring a module to another maintainer; staff already can and do do that as-needed.

As for module lists, it's technically already doable with module dependencies, but I'm pretty sure it's not something staff have any intention to support. The existing text lists of modules already cause new users enough issues as-is. (Also, any power user moving to another computer/folder can just copy their modules/ folder over and they're good to go)

feral jacinth
#

(Also, any power user moving to another computer/folder can just copy their modules/ folder over and they're good to go)
...I never thought about doing that -_-
me and my player group have multiple installations (and multiple licenses), as we run multiple campaigns with several GMs, but all using the same modules; and three times already I've gone through the tedious effort of reinstalling module-by-module