What's the release strategy? When do you plan to ship a new release?

[joanlopez]

Hello @mliebelt,

I see that despite of this repository being quite active (which makes me really happy), the last release available on NPM is from almost a year ago (v1.6.6, ~10m ago). So, I'm wondering: when do you plan to ship a new release?

But longer term, I'm also wonder, what's the release strategy?

As a (potential) user of this library (I haven't released the v0.1 of my project yet), I'd like to be able to continuously update this dependency according to all the activity it has and the care if receives. So, I'm wondering if it worths keeping a manual "vendor" of it, or just tight to NPM releases. But in the latter case, I'd love if those releases are more often.

I may try to help put some automation in place, if that would help.

Thanks!

[mliebelt]

Thank you for asking. The answer is not so easy. It is a mix of high goals, less time than expected, no clear priority what to do first, ...

I will try to have a document that describes what the current goals are, and how I want them to achieve. There is already something to find in Github itself, I will link it here.

The overall story goes like that:

• The current implementation is feature-rich, but not so easy to integrate on an API level. If you have HTML, then you are ready to go, to use the component as it is, but everything else is not supported well.
• I wanted therefore to implement an API (including notifications) that allows to integrate additional functionality much easier.
• For doing that well, I would like to have a more functional refactoring of the whole interface, at least to get rid of some dependencies (in the code) that hinder using it more easily.
• And I spent the spare hours in the last weeks to have a first integation of stockfish into the viewer (which needs much more work then).

That is the reason that I did not do any new release. I will do it soon, to push out small bug fixes, and one new mode a user did (for having something like puzzles).

So my plan now is the following:

1. Document the current way of working in the source code (some markdown file), so others can read that and understand it.
2. Have a more explicit order of the tasks I want to have done, including where new releases will be done then.
3. Then follow that plan, and try to ensure that promised releases on dates are possible.

Overall, don't expect too many new features in the next months, because that refactoring will take most of the time. My expectation is, that there may be breaking changes, at least if you wanted to integrate the viewer not only as it is, but by expanding it. What will remain for sure is the configuration of the UI, and the high level calls to integrate the viewer in HTML.

Here are additional links:

• viewer restructure project Contains all tickets, and some status and order. (was private, made it public to be transparent to others)
• overall pgn related project Concentrates more on the more functional side, lower priority to the other project

[joanlopez]

Thanks so much @mliebelt! 💟

[mliebelt]

See https://github.com/mliebelt/pgn-viewer/blob/main/roadmap.md for the public visible roadmap. Is that ok from structure and level? Is there anything missing?

[joanlopez]

Looks promising! 🔥