Wiki Wiki should be completely cleaned up to version 1.2.0 final (1 Viewer)

[rogerleifert]

Hi to all,

In my opinion there are so many entries in the Wiki which relate to changes in 1.2.0 alpha, 1.2.0 beta and 1.2.0 rc that the optical appearance is not very good.
That should all be cleared up to version 1.2.0. final

I see absolutely no reason why anybody is still running on an older version then 1.2.0.
There are so many improvements over versions 1.1.x or earlier...

I already exchanged a lot of pictures in the TV-server section with recent ones from 1.2.1. because many were outdated and didn't show all options we now have with 1.2.x

We can't forever keep references to non-existing, non-working or problematic features/options of earlier versions.
Perhaps there could be a repository for these "graveyard"-issues if anybody wants to search for outdated features/options/Problems of earlier versions.

It's time to make a cut ("tabula rasa") because 1.2.2 and 1.3.0. alpha are already in the making with again new or corrected features...

Your opinions please

Kind regards

Roger

 

[MrCrabs]

You are absolutely right! The wiki is our user's manual and since MP is developed further the wiki should mirror the newest version. But the confusion about all those 1.2. versions (alpha, beta, rc) is due to some major changes like the plugin compatiblity check that is like a cut in developement. So it is sometimes ok that there is an explicit defferentiation between pre 1.2 and after.

 

[Dadeo]

You're right, - but the timing is an issue - both when to 'force' the switch to 1.2.x, and when we have time to change all those pages.

Part of the reason we have not done it yet is I have an idea to improve the way we enter changes for test releases. Instead of entering the change in the existing page, we enter all UI changes in the What's New in 1.2.x 1.3.0, (etc.), similar to the way we enter changes that affect skins/plugins. Then the wiki page just includes a link or changelog linking to all the changes made in each version. What do you think? Would that be better?

If we go with that approach I want to move all the current changes for 1.2.0 to such a section so we can start with a 'history'

To see an example of roughly what I mean, take a look at the Changelog Table on the Button control wiki page in the Skin Architecture section.

 

[rogerleifert]

AW: Re: Wiki should be completely cleaned up to version 1.2.0 final

Hi Dadeo,

- but the timing is an issue - both when to 'force' the switch to 1.2.x, and when we have time to change all those pages.

I think the right time is really now.
I would offer to help in cleaning up the momentary WiKi. I think it's not so much work because it's mostly a deleting (or transferring to a "legacy" site) of entries.
The tearing-down part in renovating a house is also much faster than building up a new one

Part of the reason we have not done it yet is I have an idea to improve the way we enter changes for test releases. Instead of entering the change in the existing page, we enter all UI changes in the What's New in 1.2.x 1.3.0, (etc.), similar to the way we enter changes that affect skins/plugins. Then the wiki page just includes a link or changelog linking to all the changes made in each version. What do you think? Would that be better?
If we go with that approach I want to move all the current changes for 1.2.0 to such a section so we can start with a 'history'

That's a good idea.
I think either a subsuming link to a list of changes (like a kind of changelog) is much better than what we have now.
When a user enters the WiKi he should have a clean and simple look where first of all all directly visible entries are related to the latest stable release.
Additional there could be ONE conspicious link (near the upper part of the WiKi) to changes in momentary alpha, beta, RC-versions and ONE conspicious link (near the end of the WiKi) to "legacy" versions or a "history of changes" or something like that.

The only reasonable place inside the current Wiki entries, where references to older versions make sense, is concerning issues for "upgraders" from older versions.
A good example is the upgrade of the video-database to the new version especially because there also is a button for it in the configuration that must be explained.

To see an example of roughly what I mean, take a look at the Changelog Table on the Button control wiki page in the Skin Architecture section.

That looks very clean and well-arranged.

Kind regards

Roger

 

[Dadeo]

Re: AW: Re: Wiki should be completely cleaned up to version 1.2.0 final

The tearing-down part in renovating a house is also much faster than building up a new one

Heh heh, well the problem is if you are trying to reuse some of the materials! In this case I don't want to lose the changes because I think it would be useful to be able to look back at what was changed when. Mantis provides us a history of the issues/features, etc, but it does not tell you what was changed or how it affects the UI.

I think either a subsuming link to a list of changes (like a kind of changelog) is much better than what we have now.
When a user enters the WiKi he should have a clean and simple look where first of all all directly visible entries are related to the latest stable release.
Additional there could be ONE conspicious link (near the upper part of the WiKi) to changes in momentary alpha, beta, RC-versions and ONE conspicious link (near the end of the WiKi) to "legacy" versions or a "history of changes" or something like that.

Really good idea Roger. Thanks! I neglected to mention that the changelog can be automatically generated like it is on the Skin Changes wiki pages. I was trying to think about where best to add it because over time the changelog could get quite long on some pages (Videos Config in 1.2.0 is a good example!) So the bottom of the page would be less intrusive (as you said, it is not needed THAT often) The TOC is automatically generated for each wiki page, so maybe that is enough if we add it to the page - it would display a link to the Changelog at the bottom? Or I can see if we can auto add an icon/link to changelog whenever one exists.

So I need to create a few examples of how it would work, and get it right, before starting to tear down the house and that requires some complex scripting in Wiki, which I need help with. You know how hard it is to find good contractors! But it will happen! Your encouragement just means it will happen sooner, so thanks!

The only reasonable place inside the current Wiki entries, where references to older versions make sense, is concerning issues for "upgraders" from older versions.

True, but the process will also apply to new changes for test releases. For example, anyone testing 1.3.0 alpha will want to see a list of the UI changes for 1.3.0 in order to use/test them correctly. IMO that is probably the most important function of the changelog at first.

 

[rogerleifert]

AW: Re: AW: Re: Wiki should be completely cleaned up to version 1.2.0 final

Hi Dadeo,

Heh heh, well the problem is if you are trying to reuse some of the materials! In this case I don't want to lose the changes because I think it would be useful to be able to look back at what was changed when. Mantis provides us a history of the issues/features, etc, but it does not tell you what was changed or how it affects the UI.

Yeah. Of course a history of changes should be kept.
Perhaps the most clearly one would be, if there was one page with this history of changes which shows the changes combined for each major change in historical order.
At the moment it would be that the current Wiki is for 1.2.1. and the history section would have tables for 1.2.0. final, 1.2.0. RC, 1.2.0. Beta, 1.2.0. Alpha, 1.x.x. ....
The only further subdivion could be perhaps -as in the changelogs/roadmaps- TV-server, MP and Deployment tool.

I neglected to mention that the changelog can be automatically generated like it is on the Skin Changes wiki pages. I was trying to think about where best to add it because over time the changelog could get quite long on some pages (Videos Config in 1.2.0 is a good example!) So the bottom of the page would be less intrusive (as you said, it is not needed THAT often) The TOC is automatically generated for each wiki page, so maybe that is enough if we add it to the page - it would display a link to the Changelog at the bottom? Or I can see if we can auto add an icon/link to changelog whenever one exists.

Both ideas are good in my view.

So I need to create a few examples of how it would work, and get it right, before starting to tear down the house and that requires some complex scripting in Wiki, which I need help with. You know how hard it is to find good contractors! But it will happen!

Can't wait...
Sorry that I can't help you with scripting...

The only reasonable place inside the current Wiki entries, where references to older versions make sense, is concerning issues for "upgraders" from older versions.

True, but the process will also apply to new changes for test releases. For example, anyone testing 1.3.0 alpha will want to see a list of the UI changes for 1.3.0 in order to use/test them correctly. IMO that is probably the most important function of the changelog at first.

I agree.
What does make sense IMO is that the current Wiki is always based on the latest stable version but of course does show changes for current development versions (alpha, beta, RC).
(My complaint is only that when we have already have a new stable release all the backward related references to past development versions are messing up the visual appearance)

In recent history I found even the 1.2.0. alpha so much more stable, feature-enhanced and improved to the latest "stable" release (1.1.2.?) that I immediately switched to 1.2.0. alpha back then and went with much joy through the beta and RC stages
So it is of course meaningful to have references to changes in forward directed development versons.

Now as soon as a new stable version is released (last time 1.2.0./1.2.1....; next time probably when 1.3.0. final is released) would be the time to "clean up" the wiki again.

Kind regards

Roger