Version 1.0.0

[nicolasdanelon]

Hello guys,
I saw lot of big changes and improvements here.

• remove old versions of php
• support for php 7.4 and 8
• mayor cleanup for index.php file
• functionalities moved to packages

but we still keeping the 0.1X.X version code name. why? you guys have added tons of code, make big refactors and add many many mayor changes. when are you planning to release the 1.0.0 version?

I think you guys are doing the same thing that facebook did with react.

Ok, that's my little question, hope to read you soon guys. Thanks!

[ArthurHoaro]

That's a good question. I'm not exactly sure how or when we should proceed, but I'd like to see 4 major changes before moving to 1.0.0 to limit future breaking changes:

• [Feature Request] Tag docker images with version and latest #1453 rename/move Docker tags
• Use SQLite as storage for links, settings and plugin data #953 add support for RDBMS, because there might be changes in BookmarkServiceInterface
• Let the CI pipeline build and upload release archives #1555 to make release management as automated as possible
• Add a "Read later" bookmarklet #143 because I'd like to add a few major changes in the plugin system, such as custom routes

Maybe we could focus on those and decide that our new major version will 1.0.0.

[nodiscc]

• [Feature Request] Tag docker images with version and latest #1453 definitely, need to switch to a more manageable release model (one master branch/latest image, one release branch = last tag, + release branches with backported fixes)
• Let the CI pipeline build and upload release archives #1555 -> WIP: let Travis CI build release archives nodiscc/Shaarli#1 almost working. Need to figure out how to upload built .zips to GH releases
• Use SQLite as storage for links, settings and plugin data #953 definitely if there are big changes to come, would not want to release 1.0.0 and 2.0.0 in the same week :) @ArthurHoaro 0.12.1 changes are impressive, this might have warranted a minor release instead of patch :) congrats
• Add a "Read later" bookmarklet #143 same

@nicolasdanelon suggestions of what do before 1.0.0 are welcome, it would be preferable not to change interfaces too much after the release.

[nicolasdanelon]

@nodiscc no more suggestions, thanks for the space.

One thing I've notice when updated one old and lost shaarli.. can we add plugins with composer? otherwise the plugin management (at least markdown and code_coloration) is not easy to do. I can create a new issue for this one. let me know if you need more info or has this already detected.

thanks again!

[immanuelfodor]

I'm not really fond of the PHP composer idea as I'm not a PHP developer but I really love easily copying files here and there 😃 It seems my previous suggestion of a custom plugin folder got many upvotes in the past year, maybe it could solve your problem, too: #1372 (comment)

[nicolasdanelon]

@immanuelfodor thanks for your help, that link really help BUT if some dev changes the folder structure I would have a problem with my setup. If everybody works with composer (actually php) standars that won't be able to happen. ever.
@immanuelfodor what do you think about moving shaarli from json files to sqlite database?

nonetheless that docker file really help, thanks!

[immanuelfodor]

Plugins: Well, as my composer knowledge is only about composer install, I thought moving all Shaarli plugins to composer would require additional time investment from contributors and users, that's for sure. My imagined persona of a Shaarli user is a "privacy entusiast, hobby DIY tinker, docker-compose up runner", so anything harder should be guided with docs. For both the existing plugin ecosystem composer-ification (dev guide), and both the plugin installation (user guide). This is much more complex to execute than having a standard folder for local plugins, and as Python says, simple is better than complex, complex is better than complicated, and so on. 😃 The local folder could even override the included plugins to support customization, if this is needed, for example, if a code_coloration folder exists in the local folder, then it's included in Shaarli instead of the bundled.

RDBMS: I've added some comments about the topic, starting from here: #953 (comment) Arthur's last comment is relieving about intending to supporting more DB systems. I'd love to have at least one from the Maria/My/PG triplet.

[nodiscc]

regarding composer-based plugin install vs. plugins-local/ directory-based install, the directory based system is definitely better as many environments might not have composer available (and more generally build/dev utilities not strictly necessary to execution of the program should not be present on production environments - or anything that faces the Internet). So regardless of users technical level/interest, just moving files around the filesystem is the right* thing to do most of the time.