Show a version number somewhere on the page so people know what version of the tree they are testing.

[jmegenealogy]

From G2G:

The test version of the Dynamic Tree app could display a version number so you'll know exactly what testers were reporting on.

[bcaseyrls]

This is a good idea. I think we should add a "version" string to each View's "meta" content. Then it can be shown in a standard way as part of the tree info (the title, description, etc).

What sort of structure/guidelines do we want to have for the value versions?

[MichalVasut]

Yop, great idea!

[Clarke-11007]

I like that idea too - including it in the meta-data so that it gets displayed automatically and consistently makes a lot of sense. I like the idea of having it right-aligned (like the Logged into API message). As for numbering: If we each had a Major Version and Minor Version number in our metadata, I think that would be the minimum we'd need - but - I also like to include a date. SO ... my Fan Chart might be at version 1.05.2022.10.12 right now (latest update last night, on the 12th). I'm also wondering if we maybe should tack on a Major / Minor version number for the wrapper - if there are updates to the index files / Tree files. Or, do we just use the current github Commit # for that ? (currently sitting at # 95) SO... the full version number might look like : 1.05.2022.10.22 C95 Feel free to propose something simpler - that's just my suggestion, from a guy who likes to throw around a lot of numbers! -Greg :-)

…

On Thu, Oct 13, 2022 at 12:30 PM Michal Vašut ***@***.***> wrote: Yop, great idea! — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3JDGBXEDQZEY53ZBFBSOOLWDA2JJANCNFSM6AAAAAARDROT2E> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[MichalVasut]

Fun fact:

Since version 3, TeX (the typesetting system) has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated.

😊

[MichalVasut]

Btw, there is more standardized solution, check Semantic Versioning.

[bcaseyrls]

I think @MichalVasut's link is useful. A general Major.Minor.Patch scheme makes sense. With our views, though, I don't know if we'll ever have a new major branch from those guidelines. Those are for "Incompatible API Changes" (with "minor" being updated functionality and "patch" being bug fixes). Maybe we use the major version for whatever feels "major", since an isolated view isn't going to break other things even if rewritten.

I like having a date too. Maybe that goes in a separate meta() element instead of being attached to the version?

I love the idea of using π for the version number. So much so I don't think I'll go search if it's true. I want to believe regardless.

[harrislineage]

Just an idea, but could we use Major as New views, Minor as Enhanced views, Patch as ... Patches to views?

[bcaseyrls]

My thought was to have a separate version for each view, stored in their meta() content. I think perhaps it helps debug things more, but maybe that's overkill.

[harrislineage]

That sounds good. I am not familiar with releases, but would we also version the release? How would we account for changes to Tree.js, TreeAPI.js and any other third party dependency additions/changes?

[MichalVasut]

I'm not really for Tree.js releases. Maybe even for specific views. I would suggest different thing that would be totally optional. What about to add readme.md file to each view folder and there every maintainer can optionally add what he wants, relrase log, versions,... That way it will be rendered in the repo by Github an we can load it to the view using javascript.

…

On Fri, Oct 14, 2022, 15:04 Steve Harris ***@***.***> wrote: That sounds good. I am not familiar with releases, but would we also version the release? How would we account for changes to Tree.js, TreeAPI.js and any other third party dependency additions/changes? — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE72UOS53GC37OONAKZRVCLWDFK6NANCNFSM6AAAAAARDROT2E> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[MichalVasut]

<!-- meta
title: test
description: xxx
version: yyy
-->

# Release notes

2022-10-14
- added feature 1
- redactored xyz

This commented out text is not rendered by Github (when not in codeblock), but still perfectly parseable by javascript. If somebody has the need to be more creative or want do write release notes. This could be the alternative and overwrite meta fields in scripts. Also can be displayed in some modal window.

The version or date could be also parsed directly from Release notes section - the uppermost item is the current one.

[bcaseyrls]

I'm not sure I see the advantage in putting this into a readme text file. Having a "version" field in meta() seems much simpler, and then doesn't require any parsing for display. Certainly an optional readme for a view could be useful, but parsing things out of it for display in the view page doesn't seem worth it.

I think at this early stage there's much to be gained by keeping things as simple as we can. Yes, we want groundwork done for some guidelines for new contributors. But I think the more things we have that require updating, the more likely something is going to get lost, or that the burden of all of the tasks will cause more harm than help.

Is it easier to suggest an optional readme text file? Or to have an optional "version" field in meta(). And what about changes to the tree.js and other superstructure... where does that get versioned/described. This feels like a rabbit hole.