Plan for major release 2.0

[jrochkind]

Per me and @cjcolvar discussion in slack, thinking about getting some backwards incompat changes in we want to get in

• Drop dropbox adapter (@jrochkind will do it) -- we don't know anyone using it, we don't know if it actually works, and it has some inconvenient indirect dependencies (see Indirect dependency on EOL oauth2 version 1.x via dropbox-api #422). Drop dropbox-api, as a dependency, so people don't have to deal with it's dependency conflicts (see Indirect dependency on EOL oauth2 version 1.x via dropbox-api #422). dropbox adapter will remain in project, but users will have to manually add dropbox-api to their local apps to use. Not great, but lesser evil for now. Cut a 2.0 beta release if deisred.

• @cjcolvar and/or Avalon team will try to backport changes from avalon fork into this mainline, so they can be on mainline again. Since targetting a major release, it's okay if some are backwards incompat, hooray. Def cut a beta release after this for anyone to test. (We are not in contact with very many people using this to test though!)

• After getting this far, let's reconsider if any other backwards incompat changes we want to get in before final release.

  • consider front-end JS, which can't really currently be easily installed in modern JS pipelines

We are hoping this won't stretch on too long (6 months?), but since we know of very few people using this code it probably doesn't cause too much inconvenience if it does? For my use, I'm happy to use the beta(s) to get the changes I want.

[jrochkind]

One thing it really needs is a complete rewrite of front-end JS, but when I think about that I get overwhelmed -- may not be truly necessary for a major release, to the extent that there are people who are managing to use this thing anyway now (with difficulty, and not necessarily with instructions in the README!). So instructions in the READMe that actually work for installation coudl be another thing.

But I don't know we NEED to hold up a major release for these, that we don't have capacity to do? We can reconsider after getting the first two done.

[jrochkind]

@JulieWinchester writes over at #442 (comment) :

Of course! We've been using vanilla BrowseEverything for years with MorphoSource. Most of our uploads come from users via the usual Hyrax file post method, but since we're a repository where users sometimes upload files of very large file sizes (in some cases up to 30-50 GB), being able to use BrowseEverything is essential for us. We've used the Google Drive, Box, and DropBox adapters since the beginning. Maybe a year (?) ago we started using the local file folder adapter, but with a twist that we have a bit of a monkey-patch for. For users with many files or extremely large files to upload, we allow files to be transferred via Globus into user-specific upload directories. We have a monkey-patch on BrowseEverythingController to configure the file system adapter at run-time to access a particular user's specific local file directory.

Aha, you are using DropBox? We were looking for anyone that was using DropBox, because we were considering removing it!

But you are using it and it's working well for you? Can you say what version of browse-everyting you are using, and what Rails version? And any other likely dependencies?

As you can see here, we are looking at a new major version of b-e, that we'll def want to reach out to you to test on! We've been having trouble figuring out who is using B-E for what -- it's been getting very little maintenance. it's good to have connected with you.

Incidentally, if there is a fork that we should look at using if the rest of the community is moving to it, we'd be open to hearing about it.

No, we're hoping to get everyone back using the same b-e, not a fork! Do not recommend a fork. :)

[jrochkind]

We discovered osme people (namely @JulieWinchester) are still using dropbox with b-e and confimred it is working, so it has put this plan in question.

My own goal is to be able to upgrade to non-EOL supported oauth2 2.x in my app, while still using b-e.

If we can't figure out another solution, I will have to make a local fork of b-e that drops dropbox support so I can upgrade to oauth2 2.x. I'm running out of spoons.

[jrochkind]

1.6.0 has been released off current main -- I think main is ready for possible backwards incompats now for an upcoming 2.x (pre-release).

[jrochkind]

@cjcolvar and @JulieWinchester -- so note that dependency ruby-box (what even is that?) has a dependency on (unconstrained) oauth2 -- so even when we remove dropbox-api as a dependency, there is still an indirect dependency on oauth2 -- but it is now unconstrained instead of being limited to ~> 1.0, so still solves my problem.

I have no idea what ruby-box is or if it's still being used or works -- might be another one to consider removing?

[cjcolvar]

Looks like ruby-box is a box.com ruby client. It hasn't been updated in 10 years. It looks like boxr is the current accepted (but unofficial) ruby client. We should into switching to it but maybe first it could be evicted from the dependencies like dropbox-api?

[jrochkind]

OK, I'll see what i can do. Trying to figure out a reasonable Developer Experience for the non-specified-dependency.

Just document in README and that's okay, any thoughts?

It def makes the CI somewhat less reliable to have a dependency that IS included in CI (needs to be to test dropbox), but isn't included for most users -- we think it's only needed for that one adapter, but tests don't really prove that. But I guess we'll find out if people test, that's why we have betas? (ha, nobody is going to test these betas but me! and I only use s3).

[cjcolvar]

As for the 3rd point in the description, the Avalon team has been working on modernizing (or at least making some steps towards modernizing) Avalon's JS and JS dependencies. Part of this work is removing jquery as a dependency so we might work on this as well. @jrochkind can you say any more about the context of your use case? We might try to address it at the same time.

[jrochkind]

@cjcolvar Neat!

So right now I"m not sure this gem is installable without sprockets, so that needs to be fixed for modern rails... which I consider improtmap-rails or an npm-based builder, like esbuild or vite.

We do not use importmap-rails, and do use vite -- but anything that works with any npm-based installer (like anything in jsbundling-rails) should be good for us too. I think other people in samvera community require importmap-rails, so I guess needs to be compat with both? (importmap-rails is pretty tricky with npm dependencies in my experience).

Beyond that, we also would love dropping the JQuery dependency, but don't want to pick up React or similar as a dependency. Just plain rails -- relatively small npm dependencies are fine.

Does this address what you were inquiring on? If not, happy to discuss more in slack or voice!

[cjcolvar]

@jrochkind The Avalon team talked and we propose the following timeline. What do you think?

• Get tests passing on Bring in Avalon Media System changes (Google Drive improvements, Sharepoint Integration) #455 and merge it
• Cut a 2.0 release with the new features (sharepoint adapter, Rails 8.1), fixes (google drive), and major changes (optional dependencies for dropbox-api, ruby-box)
• Clean up and merge Remove jquery #453 to main (and possibly cut a release?)
• Follow on work for installation in modern JS asset pipeline environments
• Aim for 3.0 release with no jquery and modern JS by summer 2026

[jrochkind]

Hey @cjcolvar !

I would like more discussion on #453 before committing to that approach (specifically if that particular JS library is really what we want), but I can right now agree to that plan up to the second bullet, 2.0 release milestone!

I just noticed #455 haven't had a chance to review it yet, but based on it's description, seems like something we want, yeah!