Sooo many blogposts regarding updates

  • Ambassador


    In the past few days, there have been many many updates, and while i appreciate the blog posts, but i am finding it EXTRemely difficult to keep up with these (blog posts and changelogs).


    Following is the current situation, and some reasons of how i think that these are problematic.

    1. too many and too scattered blogs
      • And doing quick read for 3.2, i confused the order:
        » minor update, minor update (1), minor update (2)
        While the minor update (1) was for android 🤦♀ . Shouldnt minor update dektop be titled minor update (1) as well?? Same goes for minor update for version 3.3 as well.
    2. not to mention that the snapshots logs are even more scattered from the version they got implemented in stable
    3. I cant see 'News' and 'Snapshots' together, and the default 'All' view contains a bunch of other blogs as well.
      » why would i want to see snapshots in news??
      'cz i wasnt able to find the so crucial points in this one🡭 in any blogs in news view. (extension of 2nd point)
      » yeah, that makes sense to avoid repetition
      but then what's the solution other than these 2, cross linking maybe

    I cant seem to collect any more points at the moment, if i will more, then will add below.

    What can be done?

    See the comment below (for keeping clean, and not sidetracking discussion to my particular solution only, i.e. needless to say, keeping it open to different ways of solutions).

  • Ambassador

    What can be done?

    Structure side:

    1. The MVC can be to just collect all the stable relnotes🡭 pages and put them together in a page (say, Changelog), and give that page a prominent place/exposure on main site. (ref: sharex changelog🡭)
    2. Making individual versions RN linkable and linking the respective blogpost
      tags used:id attribute and a href
      (ref: ShareX changelog)8AePGdkCUc.gif
    3. Separating each version's RN in individual file which will:
      • ease editing
      • make the file embeddable which can be used in all other places (the new changelog page, in blog posts, in update checker). Thus reducing duplicacy.
        (compare RN2022.45🡭 and RN2022.39🡭 for duplicacy example).
      • would make following things possible:
    4. Paginating and Sorting the new Changelog. (both inspired from GitLab)
      For example, sort by:
      • latest first (date ⬇ - default) or oldest first (date ⬆)
      • versions : Major ⬇ > Minor ⬇ > Patch ⬆
        so, 4.0.0 > 3.9.0 > 3.9.1 > 3.8.0 > 3.8.1
        this way, bug fix releases will come after/below the minor versions
        this sorting scheme should apply to vivaldi versioning too with no problems

    Content side:

    1. "current version" must be given too, release date would be nice as well (ref: sharex). So, it will become something like:
      Vivaldi --current version-- on --date-- [since Vivaldi --last version--]
      I am lightly against removing the currently given since --last version--.
    2. Where there are many items in say, [category1] , those be grouped.
      Just like it's done in the 3.3 blog🡭 : Screenshot.png


    compulsory: Structure: 1, & 2. Content: 1st
    would be nice plus: Structure: 3rd (back-end), Content: 2nd
    totally optional: Structure: 4th
    not decided: below

    Additional input:

    These are the additional ideas, which i was not able to decide for/against. So, just posting here anyways:

    1. I tried embedding via iframe, hoping for some better method. (very beginner in HTML)
    2. Should accordion menu/details tag be used for hiding older versions details??
    3. In update checker, link can be given to the new changelog page (ref: sharex). I would like both: link and smth like current shown changelog
    4. The update of the changelog can be set to autoupdate too. (if autofetching new files can be set up. Ref: like in file:/// or ftp:// protocol - thread🡭)
    5. To replace the current OTG rendered relnotes page in vivaldi update checker:
      • a page/script/code can be setup which fetches/embeds the desired amount of latest files - similar to pagination. (files = versions' RN files, desired = by the team).
      • The fetching can be manual (as in links are updated manually) or similar to above point, be automatic.
      • So, just one page will be there for update checker. (rather than current - where there's a new relnotes page for every releases).

    I have tried to make an html prototype, and will post a video soon. if anything else (other than vid) is required too, please tell me 🙂


  • Ambassador

    reserving a post, just in case.

    old version of my post (refined, originally, it was messier 😅):

    What can be done?

    It would have been nice if there was some sort of summary view. For example, the to-the-point or quick changelog view from the in-app updater is a nice starting point. yes, i know that these are given at the end of individual version blogs, but there's no page listing a sensible number of these together.

    okay, so, i didnt know that there is already an official page for the release notes - which is publicly available - just found out from the comment🡭. And so, my initial proposal is even more less work 🙂

    Right now, relnotes is just one whole html page all written directly in every file. So, i am thinking about 3 things on structural level:

    1. each version has its RN (release note) in a separate file
    2. having all those files open inline in a page (this pg will become final changelog pg) - like with iframe or smth
    3. having the bloging pages support embedding for this file (not necessary, but will make things much easier after implementation i guess)
    4. ignore this one
      adopting a tree structure - with arrow for directory (like accordian/detail view) or click for files

    This will:

    • show all RNs in one page
    • while still keep the changelog of each version separately referable too
    • make each page's RN easier to modify (if ever needs, for e.g. in that error)
    • remove the redundancy of copy-pasting older logs in new logs (compare RN2022.45🡭 and RN2022.39🡭 for example)
    • remove redundancy of pasting these in blog posts

    The changes/additions i'd suggest in this view (on content level) would be:

    • to have 2 more levels of grouping:
      • bugfix updates be grouped under the minor updates
      • and where there are many items in say, [category1] , those be grouped (like in 3.3 blog)
    • to provide a link to the respective/dedicated blog posts.
    • "changes in (version)" and release date be given as well. currently only "changes since (last version)" is written in handing.

    see ref: ShareX Changelog 8355c07a-a67f-4a57-8367-51c8b526389f-image.png

  • People should click on that ShareX graphic in order to see what a real changelog should look like.

    ALL ON ONE PAGE is key. This allows not only ease but searching for things of interest. Doing that now is torture.

    Piecemeal changelogs like this with obscure URLs don't cut it:

    Fix the URL and keep the log going, going, going. The Internet will allow it.

    As for snapshots, of course don't mix them into the release changelog. Perhaps they should have their own though for historical reference (no, hunting through blog posts is not practical). This is not as important as the release changelog but would be far from difficult to do.

Log in to reply

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.