Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow ad hoc releases of experimental core plugins #8477

Open
Jermolene opened this issue Aug 3, 2024 · 4 comments
Open

Allow ad hoc releases of experimental core plugins #8477

Jermolene opened this issue Aug 3, 2024 · 4 comments

Comments

@Jermolene
Copy link
Member

It is proposed that plugins whose stability level is "experimental" be allowed to follow their own release schedule, with releases going to production as soon as they are ready.

There are a few changes that will need to be coordinated to make this happen:

  • Allow plugins to specify a minimum core version beyond which they will refuse to be installed
  • Give plugins a "Release Notes" or "Changelog" tab with a structured display of changes to the plugin
  • Devise and document the release procedure (which is essentially copying files under 'plugins/tiddlywiki/*' from 'master' to 'tiddlywiki-com')

For the release notes, the tiddler $:/plugins/tiddlywiki/pluginname/changelog would be a data dictionary mapping version numbers to a brief description of the release of the form 2024-08-24 Description of this update. If plugins wish to add more documentation about a release they can use tiddlers incorporating the version number of the form $:/plugins/tiddlywiki/pluginname/changelog/v1.0.0 that would contain the full description of the release.

@pmario
Copy link
Member

pmario commented Aug 3, 2024

I think, that the full description of the plugin-history should be part of a demo-edition.

The plugin itself should only contain the minimal changelog-info. Over time there may be plugins, where the history is much longer than the plugin code itself.

I personally consider this a waste of space.

eg: My custom-markup plugin has a long list of history. The plugin itself only contains the latest 2 or 3 points and a link to the full history on the demo page.

Part of the plugin

image


Part of the Demo Page

image

@Jermolene
Copy link
Member Author

I think, that the full description of the plugin-history should be part of a demo-edition.

The plugin itself should only contain the minimal changelog-info. Over time there may be plugins, where the history is much longer than the plugin code itself.

With the scheme I outlined it is entirely up to the plugin publisher how much information they retain.

@pmario
Copy link
Member

pmario commented Aug 3, 2024

With the scheme I outlined it is entirely up to the plugin publisher how much information they retain.

That's right. But I was thinking about core plugins. We should also try to keep it minimalistic

@Jermolene
Copy link
Member Author

Hi @pmario generally I do not share your concern about wasting space. When and if we encounter the problem where a core plugin has overly length release notes we can consider policies for dealing with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants